Property Iteration in JSON serialization

[Brian Kardell]

Because the serialized form (json text) and the native source form (a
specific subset of object literals) are essentially the same, I have
occasionally heard people "in the wild" refer to both literals
themselves and instances of an object parsed from json text as "json".
 Clearly the two are different things which leads me to my question:
With new built in json supports one can serialize an instance of an
object as json text and provide some serialization criteria (a
whilelist or a replacer function) - on the other end easily
de-serialize that back into instance. Great!  One of the great things
about json is that it's quite a readable format and, as Doug Crockford
points out, expresses things in ways that they are naturally thought
about in most modern (especially C-family) languages - so it's very
easy to parse from a machine point of view too and get right to a
useful instance instead of some DOM tree of string values.

So - keeping in mind that the instance and the serialization are
separate things - what if I would like to order my serialization keys
(property names) in natural order?  It has no impact on the parsing or
internal representation, but imposing a known order on the
serialization, even a trivial one, makes things easier to find and
documentation easier to understand.  We've implemented this in a few
local serializers in multiple languages and, since during
serialization we are writing them out by iterating the keys, it's
actually quite trivial to merely call sort() on the keys before
iteration.  Likewise, since this only has to be done once per type -
not once per instance, there is very, very minimal overhead (you are
generally sorting less than 20 keys regardless of the number of
instances).

There are potentially some additional practical upshots beyond human
readability to this which I won't get into here until I find out:  Is
it even plausible to accomplish this with new built in JSON supports?

To be specific, if it's not clear... Given an instance of an order
object, I would like to serialize it like this:

{
    "items": [
        {
            "description": "A bottle of rum",
            "itemId":  13523,
            "price": 12.94,
            "quantity": 6
        },
        {
            "description": "A bottle of whiskey",
            "itemId":  23423,
            "price": 6.95,
            "quantity": 24
        }
    ],
    "orderNumber": 1234123,
    "shipTo": {
        "city": "Seattle",
        "name": "Jane Doe",
        "state": "Washington",
        "streetAddress": "123 Main Street",
        "zip": 12345
    }
}
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[David-Sarah Hopwood-2]

Brian Kardell wrote:

> So - keeping in mind that the instance and the serialization are
> separate things - what if I would like to order my serialization keys
> (property names) in natural order?  It has no impact on the parsing or
> internal representation, but imposing a known order on the
> serialization, even a trivial one, makes things easier to find and
> documentation easier to understand.  We've implemented this in a few
> local serializers in multiple languages and, since during
> serialization we are writing them out by iterating the keys, it's
> actually quite trivial to merely call sort() on the keys before
> iteration.  Likewise, since this only has to be done once per type -
> not once per instance, there is very, very minimal overhead (you are
> generally sorting less than 20 keys regardless of the number of
> instances).

Well, JS doesn't have types in that sense. So, unless an implementation
were to exploit any internal optimizations it has for recognizing objects
of the same "shape" [*], it would indeed have to sort the keys of every
instance.


[*] Do any common implementations actually do that, other than for
    packed arrays?

--
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Graydon Hoare-3]

David-Sarah Hopwood wrote:

> [*] Do any common implementations actually do that, other than for
>     packed arrays?

Yes. All the fast ones. Nitro (nee sfx), v8 and spidermonkey all
synthesize structural type descriptors ("shapes") at runtime and store
packed instances, tagged by shape. It's an old trick and pays off well.

(This comment is orthogonal to any conversation about JSON, mind you.)

-Graydon
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Lucas Smith-2]

On Oct 13, 2009, at 9:24 PM, Brian Kardell wrote:

>
> There are potentially some additional practical upshots beyond human
> readability to this which I won't get into here until I find out:  Is
> it even plausible to accomplish this with new built in JSON supports?
>
> To be specific, if it's not clear... Given an instance of an order
> object, I would like to serialize it like this:
>
> {
>    "items": [
>        {
>            "description": "A bottle of rum",
>            "itemId":  13523,
>            "price": 12.94,
>            "quantity": 6
>        },
>        {
>            "description": "A bottle of whiskey",
>            "itemId":  23423,
>            "price": 6.95,
>            "quantity": 24
>        }
>    ],
>    "orderNumber": 1234123,
>    "shipTo": {
>        "city": "Seattle",
>        "name": "Jane Doe",
>        "state": "Washington",
>        "streetAddress": "123 Main Street",
>        "zip": 12345
>    }
> }

It is possible to sort object keys in a replacer function.  See http://gist.github.com/209826

Currently FF3.5.4 doesn't properly apply replacer functions, but  
Safari 4, WebKit, IE8, and Chrome 3 work fine for this task.

Luke
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brian Kardell]

On Tue, Oct 13, 2009 at 10:54 PM, Luke Smith <lsmith@...> wrote:

>
> On Oct 13, 2009, at 9:24 PM, Brian Kardell wrote:
>
>>
>> There are potentially some additional practical upshots beyond human
>> readability to this which I won't get into here until I find out:  Is
>> it even plausible to accomplish this with new built in JSON supports?
>>
>> To be specific, if it's not clear... Given an instance of an order
>> object, I would like to serialize it like this:
>>
>> {
>>   "items": [
>>       {
>>           "description": "A bottle of rum",
>>           "itemId":  13523,
>>           "price": 12.94,
>>           "quantity": 6
>>       },
>>       {
>>           "description": "A bottle of whiskey",
>>           "itemId":  23423,
>>           "price": 6.95,
>>           "quantity": 24
>>       }
>>   ],
>>   "orderNumber": 1234123,
>>   "shipTo": {
>>       "city": "Seattle",
>>       "name": "Jane Doe",
>>       "state": "Washington",
>>       "streetAddress": "123 Main Street",
>>       "zip": 12345
>>   }
>> }
>
> It is possible to sort object keys in a replacer function.  See
> http://gist.github.com/209826
>
> Currently FF3.5.4 doesn't properly apply replacer functions, but Safari 4,
> WebKit, IE8, and Chrome 3 work fine for this task.
>
> Luke
>

But I guess your example gets to the gist (ironically, given the url)
of the question: It seems to be implying that there is a specific
(insertion) order maintained by the instance itself and reflected in
iteration... The difference being something more like a TreeMap than a
HashMap - but is that part of the specification?  I thought that it
specifically wasn't.
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Oliver Hunt-2]

> Currently FF3.5.4 doesn't properly apply replacer functions, but  
> Safari 4, WebKit, IE8, and Chrome 3 work fine for this task.

For the purpose of discussion webkit and safari (and epiphany, and  
arora, ...) are synonymous -- chrome represents the only version of  
webkit using a unique JS engine.  I think for that reason it's better  
to distinguish based on JS engine rather the browser: SpiderMonkey,  
JavaScriptCore, V8, and JScript all support JSON natively nowadays --  
unsure about any opera betas atm, nor what the JS engine in O is named,

That said, the Safari 4 branch of webkit (which i believe is used as  
the stable branch for WebKit/qt as well) has a bug where it provides  
the global object rather than the holder object as the `this` argument  
to the replacer function.

--Oliver

>
> Luke
> _______________________________________________
> es-discuss mailing list
> es-discuss@...
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Oliver Hunt-2]

> But I guess your example gets to the gist (ironically, given the url)
> of the question: It seems to be implying that there is a specific
> (insertion) order maintained by the instance itself and reflected in
> iteration... The difference being something more like a TreeMap than a
> HashMap - but is that part of the specification?  I thought that it
> specifically wasn't.

All ES implementations are required to enumerate object properties in  
the order of insertion, regardless of internal representation, and the  
JSON object definition defines the replacer execution in terms of that  
standard object enumeration.

--Oliver

> _______________________________________________
> es-discuss mailing list
> es-discuss@...
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brian Kardell]

Awesome - just the answer I was looking for Oliver - thanks!


On Tue, Oct 13, 2009 at 11:42 PM, Oliver Hunt <oliver@...> wrote:

>> But I guess your example gets to the gist (ironically, given the url)
>> of the question: It seems to be implying that there is a specific
>> (insertion) order maintained by the instance itself and reflected in
>> iteration... The difference being something more like a TreeMap than a
>> HashMap - but is that part of the specification?  I thought that it
>> specifically wasn't.
>
> All ES implementations are required to enumerate object properties in the
> order of insertion, regardless of internal representation, and the JSON
> object definition defines the replacer execution in terms of that standard
> object enumeration.
>
> --Oliver
>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@...
>> https://mail.mozilla.org/listinfo/es-discuss
>
>

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Patrick Mueller]

On Oct 14, 2009, at 2:42 AM, Oliver Hunt wrote:

> All ES implementations are required to enumerate object properties  
> in the order of insertion, regardless of internal representation,  
> and the JSON object definition defines the replacer execution in  
> terms of that standard object enumeration.

I understand that's what all (or most) of the implementations actually  
do, but the ES5 spec I'm looking at - Ecma/TC39/2009/043 - doesn't  
actually say it's required.

In 12.6.4 discussing the for-in statement, it says: "The mechanics and  
order of enumerating the properties (step 6.a in the first algorithm,  
step 7.a in the second) is not specified."

In 15.2.3.14 discussion Object.keys(), it says: "If an implementation  
defines a specific order of enumeration for the for-in statement, that  
same enumeration order must be used in step 5 of this algorithm."

In 15.12.2 discussing JSON.parse(), it says: "The ordering of the  
Strings should be the same as that used by the Object.keys standard  
built-in function."

In 15.12.3 discussing JSON.stringify(), it says: "The ordering of the  
Strings should be the same as that used by the Object.keys standard  
built-in function."

Sorry, property ordering is an unfortunate pet peeve of mine.  :-)

Patrick Mueller - http://muellerware.org/




_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brian Kardell]

On Wed, Oct 14, 2009 at 5:41 AM, Patrick Mueller <pmuellr@...> wrote:

> On Oct 14, 2009, at 2:42 AM, Oliver Hunt wrote:
>
>> All ES implementations are required to enumerate object properties in the
>> order of insertion, regardless of internal representation, and the JSON
>> object definition defines the replacer execution in terms of that standard
>> object enumeration.
>
> I understand that's what all (or most) of the implementations actually do,
> but the ES5 spec I'm looking at - Ecma/TC39/2009/043 - doesn't actually say
> it's required.
>
> In 12.6.4 discussing the for-in statement, it says: "The mechanics and order
> of enumerating the properties (step 6.a in the first algorithm, step 7.a in
> the second) is not specified."
>
> In 15.2.3.14 discussion Object.keys(), it says: "If an implementation
> defines a specific order of enumeration for the for-in statement, that same
> enumeration order must be used in step 5 of this algorithm."
>
> In 15.12.2 discussing JSON.parse(), it says: "The ordering of the Strings
> should be the same as that used by the Object.keys standard built-in
> function."
>
> In 15.12.3 discussing JSON.stringify(), it says: "The ordering of the
> Strings should be the same as that used by the Object.keys standard built-in
> function."
>
> Sorry, property ordering is an unfortunate pet peeve of mine.  :-)
>
> Patrick Mueller - http://muellerware.org/
>
>

Uh oh... Patrick looking at the same parts as me reacting the same way
(I believe older pre-5 docs also said something similar)...
When Oliver said "All ES implementations are required to..." I assumed
that I missed something in the new 5 docs - not that everyone just
seems to have implemented roughly the same thing...

Is it required - or is it not?
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

We talked about requiring it. It's a de-facto standard, followed for  
direct ("own") properties of most objects. Exceptions may include  
arrays (possibly only dense) and host object (of course)!

I'm committed to helping ensure we get better for-in specification --  
and meta-programming -- in Harmony. For now the de-facto standard of  
for-in enumerating in insertion order is pretty strong without a de-
jure spec.

/be

On Oct 14, 2009, at 9:27 AM, Brian Kardell wrote:

> On Wed, Oct 14, 2009 at 5:41 AM, Patrick Mueller <pmuellr@...>  
> wrote:
>> On Oct 14, 2009, at 2:42 AM, Oliver Hunt wrote:
>>
>>> All ES implementations are required to enumerate object properties  
>>> in the
>>> order of insertion, regardless of internal representation, and the  
>>> JSON
>>> object definition defines the replacer execution in terms of that  
>>> standard
>>> object enumeration.
>>
>> I understand that's what all (or most) of the implementations  
>> actually do,
>> but the ES5 spec I'm looking at - Ecma/TC39/2009/043 - doesn't  
>> actually say
>> it's required.
>>
>> In 12.6.4 discussing the for-in statement, it says: "The mechanics  
>> and order
>> of enumerating the properties (step 6.a in the first algorithm,  
>> step 7.a in
>> the second) is not specified."
>>
>> In 15.2.3.14 discussion Object.keys(), it says: "If an implementation
>> defines a specific order of enumeration for the for-in statement,  
>> that same
>> enumeration order must be used in step 5 of this algorithm."
>>
>> In 15.12.2 discussing JSON.parse(), it says: "The ordering of the  
>> Strings
>> should be the same as that used by the Object.keys standard built-in
>> function."
>>
>> In 15.12.3 discussing JSON.stringify(), it says: "The ordering of the
>> Strings should be the same as that used by the Object.keys standard  
>> built-in
>> function."
>>
>> Sorry, property ordering is an unfortunate pet peeve of mine.  :-)
>>
>> Patrick Mueller - http://muellerware.org/
>>
>>
>
> Uh oh... Patrick looking at the same parts as me reacting the same way
> (I believe older pre-5 docs also said something similar)...
> When Oliver said "All ES implementations are required to..." I assumed
> that I missed something in the new 5 docs - not that everyone just
> seems to have implemented roughly the same thing...
>
> Is it required - or is it not?
> _______________________________________________
> es-discuss mailing list
> es-discuss@...
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Hallvord R. M. Steen]

Siterer Brendan Eich <brendan@...>:

>>>> All ES implementations are required to enumerate object properties in the
>>>> order of insertion, regardless of internal representation

>> Is it required - or is it not?

It's not (yet) a spec requirement but in our experience it is  
definitely required if you want to handle web content. Opera used to  
return properties in some implementation-specific order (apparently  
random from the script's point of view) and we had to change it  
because it caused bugs on GMail and several other sites. (Though I  
think we still return numerical properties on regular objects in an  
unexpected order and haven't had as many problems with those).

- Hallvord R.

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Waldemar Horwat]

Brian Kardell wrote:
> Uh oh... Patrick looking at the same parts as me reacting the same way
> (I believe older pre-5 docs also said something similar)...
> When Oliver said "All ES implementations are required to..." I assumed
> that I missed something in the new 5 docs - not that everyone just
> seems to have implemented roughly the same thing...
>
> Is it required - or is it not?

It is not required.  We were planning to make it required for ES5 but it turns out that implementations do not match each other and implementations do not follow insertion order for some kinds of properties such as things that could be used as array indices.  Requiring insertion order would make iterating over arrays weird.

    Waldemar
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brian Kardell]

It sounds to me like there is wide agreement in the sense that at
least the basics rules and only disagreement on the fringes...
Otherwise no one on this list in particular would be suggesting that
there is anything remotely like a "de facto" implementation... It
seems that at least those basic rules are required just to function
with the existing expectations everywhere.

It also seems that those expectations aren't likely to change any time
soon for the "default" for-each iteration order whether more robust
and interesting proposals are adopted...

So can't that much be formalized and documented regardless of whether
or not new introductions are made to over-ride "other" predictable
iterators to be used in for-each (or perhaps even some new mechanism
entirely)? The simple fact that conforming to the spec would currently
create a non-workable solution seems to argue that at least the "de
facto" parts should be included...

No?



On Wed, Oct 14, 2009 at 2:37 PM, Waldemar Horwat <waldemar@...> wrote:

> Brian Kardell wrote:
>>
>> Uh oh... Patrick looking at the same parts as me reacting the same way
>> (I believe older pre-5 docs also said something similar)...
>> When Oliver said "All ES implementations are required to..." I assumed
>> that I missed something in the new 5 docs - not that everyone just
>> seems to have implemented roughly the same thing...
>>
>> Is it required - or is it not?
>
> It is not required.  We were planning to make it required for ES5 but it
> turns out that implementations do not match each other and implementations
> do not follow insertion order for some kinds of properties such as things
> that could be used as array indices.  Requiring insertion order would make
> iterating over arrays weird.
>
>   Waldemar
>

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

The issue is not overriding default for-in behavior (as you can do in  
JS1.7 via __iterator__). The issue is the default behavior.

Waldemar's right, browsers differ on Array enumeration, for some or  
all Arrays. My observation to TC39 when we last discussed this is that  
most arrays are populated front to back (0 to high index) so insertion  
order matches index order, and that most programmers (all I've ever  
polled or heard from) want array enumeration to use index order.

It's conceivable that we could standardize insertion order for named  
properties, index order for indexed properties (for all objects, not  
just for Arrays). I don't know how this will fly; some VMs already  
optimize this way (v8 does, IIRC). I think it's a good compromise,  
since the edge case behavior in different browsers does not allow edge-
case-testing scripts to interoperate today.

But this will take someone (my name was on it at the end of the last  
TC39 meeting) writing up a proposal. I will make time this month for it.

/be

On Oct 14, 2009, at 4:11 PM, Brian Kardell wrote:

> It sounds to me like there is wide agreement in the sense that at
> least the basics rules and only disagreement on the fringes...
> Otherwise no one on this list in particular would be suggesting that
> there is anything remotely like a "de facto" implementation... It
> seems that at least those basic rules are required just to function
> with the existing expectations everywhere.
>
> It also seems that those expectations aren't likely to change any time
> soon for the "default" for-each iteration order whether more robust
> and interesting proposals are adopted...
>
> So can't that much be formalized and documented regardless of whether
> or not new introductions are made to over-ride "other" predictable
> iterators to be used in for-each (or perhaps even some new mechanism
> entirely)? The simple fact that conforming to the spec would currently
> create a non-workable solution seems to argue that at least the "de
> facto" parts should be included...
>
> No?
>
>
>
> On Wed, Oct 14, 2009 at 2:37 PM, Waldemar Horwat  
> <waldemar@...> wrote:
>> Brian Kardell wrote:
>>>
>>> Uh oh... Patrick looking at the same parts as me reacting the same  
>>> way
>>> (I believe older pre-5 docs also said something similar)...
>>> When Oliver said "All ES implementations are required to..." I  
>>> assumed
>>> that I missed something in the new 5 docs - not that everyone just
>>> seems to have implemented roughly the same thing...
>>>
>>> Is it required - or is it not?
>>
>> It is not required.  We were planning to make it required for ES5  
>> but it
>> turns out that implementations do not match each other and  
>> implementations
>> do not follow insertion order for some kinds of properties such as  
>> things
>> that could be used as array indices.  Requiring insertion order  
>> would make
>> iterating over arrays weird.
>>
>>   Waldemar
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss@...
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Waldemar Horwat]

Brian Kardell wrote:

> It sounds to me like there is wide agreement in the sense that at
> least the basics rules and only disagreement on the fringes...
> Otherwise no one on this list in particular would be suggesting that
> there is anything remotely like a "de facto" implementation... It
> seems that at least those basic rules are required just to function
> with the existing expectations everywhere.
>
> It also seems that those expectations aren't likely to change any time
> soon for the "default" for-each iteration order whether more robust
> and interesting proposals are adopted...
>
> So can't that much be formalized and documented regardless of whether
> or not new introductions are made to over-ride "other" predictable
> iterators to be used in for-each (or perhaps even some new mechanism
> entirely)? The simple fact that conforming to the spec would currently
> create a non-workable solution seems to argue that at least the "de
> facto" parts should be included...
>
> No?

No.  As I wrote, there is no de-facto implementation order because the implementations do not agree on the order in general, and what you call "fringes" such as numbers do matter.  Trying to force, say, insertion order would likely break compatibility.

    Waldemar
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Jeff Walden-6]

On 10/13/2009 10:54 PM, Luke Smith wrote:
> Currently FF3.5.4 doesn't properly apply replacer functions, but Safari
> 4, WebKit, IE8, and Chrome 3 work fine for this task.

How precisely are replacer functions not properly applied in Firefox?  I remember reporting at least one bug on the replacer-function implementation that was fixed for 3.5 or a beta of it, and to the best of my knowledge they work fine, outside of a few cases such as for circular data structures (and the semantic difference there, if you're not looking for it, probably won't matter much anyway).  Have you reported a bug for this at bugzilla.mozilla.org?

Jeff
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Mike Shaver]

On Wed, Oct 14, 2009 at 7:24 PM, Waldemar Horwat <waldemar@...> wrote:
> No.  As I wrote, there is no de-facto implementation order because the
> implementations do not agree on the order in general, and what you call
> "fringes" such as numbers do matter.  Trying to force, say, insertion order
> would likely break compatibility.

IIRC, Firefox before FF3 used insertion order for arrays as well as
objects, and changed to index order for arrays in FF3.  I don't recall
any compat problems on either side of the transition with respect to
array iteration order.

Mike
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Mike Shaver]

On Wed, Oct 14, 2009 at 7:39 PM, Jeff Walden <jwalden+es@...> wrote:

> On 10/13/2009 10:54 PM, Luke Smith wrote:
>>
>> Currently FF3.5.4 doesn't properly apply replacer functions, but Safari
>> 4, WebKit, IE8, and Chrome 3 work fine for this task.
>
> How precisely are replacer functions not properly applied in Firefox?  I
> remember reporting at least one bug on the replacer-function implementation
> that was fixed for 3.5 or a beta of it, and to the best of my knowledge they
> work fine, outside of a few cases such as for circular data structures (and
> the semantic difference there, if you're not looking for it, probably won't
> matter much anyway).  Have you reported a bug for this at
> bugzilla.mozilla.org?

Yes, he did: https://bugzilla.mozilla.org/show_bug.cgi?id=509184

Mike
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Allen Wirfs-Brock-2]

It's probably too late for us to take advantage of this, but it did just occur to me (too much document.all discussion) that since for-in is a syntactic construct its behavior could be different in strict mode, potentially allowing us to define a for-in enumeration order that isn't tried to legacy behavior.

Similarly, rather than trying to fully specifying for-in enumeration order (and invariably causing potentially breaking changes for some implementations) we could specify a new enumeration statement that uses a strictly specified order.  By suggest for this would be:
   for names (n in expr) ...
and
   for values (v in expr) ...

avoiding conflicts with the existing for-in and E4X for-each.

Allen

>-----Original Message-----
>From: es-discuss-bounces@... [mailto:es-discuss-
>bounces@...] On Behalf Of Mike Shaver
>Sent: Wednesday, October 14, 2009 6:30 PM
>To: Waldemar Horwat
>Cc: es-discuss
>Subject: Re: Property Iteration in JSON serialization
>
>On Wed, Oct 14, 2009 at 7:24 PM, Waldemar Horwat <waldemar@...>
>wrote:
>> No.  As I wrote, there is no de-facto implementation order because the
>> implementations do not agree on the order in general, and what you
>call
>> "fringes" such as numbers do matter.  Trying to force, say, insertion
>order
>> would likely break compatibility.
>
>IIRC, Firefox before FF3 used insertion order for arrays as well as
>objects, and changed to index order for arrays in FF3.  I don't recall
>any compat problems on either side of the transition with respect to
>array iteration order.
>
>Mike
>_______________________________________________
>es-discuss mailing list
>es-discuss@...
>https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss