On Dec 7, 2013, at 6:39 PM, Bjoern Hoehrmann wrote:

> * Allen Wirfs-Brock wrote:
>> On Dec 7, 2013, at 4:55 PM, John Cowan wrote:
>>> Allen Wirfs-Brock scripsit:
>>> 
>>>> Similarly, the JSON texts:
>>>>  {"1":  1, "2", 2}
>>>> and
>>>>  {"2":  2, "1": 1}
>>>> 
>>>> or the JSON texts:
>>>>  {"a": 1, "a": 2}
>>>> and
>>>>  {"a": 2, "a": 1}
>>>> 
>>>> have an ordering of the object members that must be preserved by the
>>>> parser in order for downstream semantics to be applied.
>>> 
>>> I cannot accept this statement without proof.  Where in the ECMAscript
>>> definition does it say this?
> 
>> In other words, ECMA-262 explicitly specifies that when multiple 
>> occurrences of the same member name occurs in a JSON object, the value 
>> associated with the last (right-most) occurrence is used. Order matters.
>> 
>> A similar analysis applies to the first example.  
> 
> Your analysis does not demonstrate that `JSON.parse` preserves ordering.
> I am confident that even in the current ES6 draft `JSON.stringify` does
> not preserve ordering even if `JSON.parse` somehow did. It's based on
> `Object.keys` which does not define ordering as currently proposed. If
> you can re-create the key-value-pair order in your first example from
> the output of `JSON.parse` without depending on implementation-defined
> behavior, seeing the code for that would be most instructive.


You are correct that, ES5 does not define the for-in enumeration order.  But it does say that the Object.keys ordering must be the same as  for-in enumeration order. and there is a defacto standard for a partial enumeration order that all browsers implement.

Quoting from  https://mail.mozilla.org/htdig/es-discuss/2009-October/010060.html 
"The common behavior subset here is: for objects with no properties  
that look like array indices, and no enumerable prototype properties,  
for..in enumeration returns properties in insertion order. That  
particular behavior is a de facto standard and required for Web  
compatibility. A future standard should specify at least that much. "

Also https://mail.mozilla.org/pipermail/es-discuss/2010-December/012469.html 
"We did identify one situation where enumeration order will be the same across all major implementation that are currently in use (including IE6):

The enumeration order of an object's properties will be the order in which the properties were added if all the following conditions hold:
	The object has no inherited enumerable properties
	The object has no array indexed properties
	No properties have been deleted
	No property has had its attributes modified or been changed from a data property to an accessor property or visa versa
"

Also see https://mail.mozilla.org/pipermail/es-discuss/2011-March/012965.html must other discussion history you can find in the es-discuss archives.

In practice, JavaScript implementation do have a standard enumeration order that applies for the cases that most commonly when parsing and generating JSON text. Application do depend upon that ordering.

Allen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131207/efa259ee/attachment.html>

On Dec 7, 2013, at 6:39 PM, Bjoern Hoehrmann wrote:

> Your analysis does not demonstrate that `JSON.parse` preserves ordering.
> I am confident that even in the current ES6 draft `JSON.stringify` does
> not preserve ordering even if `JSON.parse` somehow did. It's based on
> `Object.keys` which does not define ordering as currently proposed. If
> you can re-create the key-value-pair order in your first example from
> the output of `JSON.parse` without depending on implementation-defined
> behavior, seeing the code for that would be most instructive.


You are correct that, ES5 does not define the for-in enumeration order.  But it does say that the Object.keys ordering must be the same as  for-in enumeration order. and there is a defacto standard for a partial enumeration order that all browsers implement.

Quoting from  https://mail.mozilla.org/htdig/es-discuss/2009-October/010060.html:

> The common behavior subset here is: for objects with no properties  that look like array indices, and no enumerable prototype properties,  for..in enumeration returns properties in insertion order. That particular behavior is a de facto standard and required for Web compatibility. A future standard should specify at least that much.

Also https://mail.mozilla.org/pipermail/es-discuss/2010-December/012469.html:

> We did identify one situation where enumeration order will be the same across all major implementation that are currently in use (including IE6):
>
> The enumeration order of an object's properties will be the order in which the properties were added if all the following conditions hold:
>
> - The object has no inherited enumerable properties
> - The object has no array indexed properties
> - No properties have been deleted
> - No property has had its attributes modified or been changed from a data property to an accessor property or visa versa

Also see https://mail.mozilla.org/pipermail/es-discuss/2011-March/012965.html must other discussion history you can find in the es-discuss archives.

In practice, JavaScript implementation do have a standard enumeration order that applies for the cases that most commonly when parsing and generating JSON text. Application do depend upon that ordering.