Property Iteration in JSON serialization

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Property Iteration in JSON serialization

Brian Kardell
Sure, but again... Without any changes it currently reads:

"The mechanics and order of enumerating the properties (step 6.a in
the first algorithm, step 7.a in the second) is not specified. "

Which isn't really necessary even currently (pre-5 I think) doesn't
accurately describe what seems to be the de-facto standard.  It should
be relatively easy to merely codify what is already implemented
everywhere which sounds like without any disagreement or "new"
proposals it could say something along the lines of:

"For objects containing no indexed properties the mechanics and
default order of enumerating the properties (step 6.a in the first
algorithm, step 7.a in the second) is specified as insertion order.
For reasons of historical compatibility, the default order of
enumerating the properties of objects which contain indexed properties
is not specified. "


That's not to say that no further effort should be made to take it
even further, but I for one would find something like the above a lot
more comforting and realistic than nothing at all if it comes to that.



On Wed, Oct 14, 2009 at 7:01 PM, Allen Wirfs-Brock
<[hidden email]> wrote:

> 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: [hidden email] [mailto:es-discuss-
>>[hidden email]] 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 <[hidden email]>
>>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
>>[hidden email]
>>https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Property Iteration in JSON serialization

Brian Kardell
In reply to this post by Waldemar Horwat
Sorry... somehow Waldemar's comment got closed up in my Gmail
conversation stack and I missed this comment...

If Oliver and  Hallvord and Brendan are wrong on the idea that it is
at least largely already a de facto standard for non-indexed
properties then  I suppose it is a moot point...






On Wed, Oct 14, 2009 at 4:24 PM, Waldemar Horwat <[hidden email]> wrote:

> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Property Iteration in JSON serialization

Brendan Eich-3
In reply to this post by Allen Wirfs-Brock-2
On Oct 14, 2009, at 7:01 PM, Allen Wirfs-Brock wrote:

> Similarly, rather than trying to fully specifying for-in enumeration  
> order (and invariably causing potentially breaking changes for some  
> implementations)

I'm focusing on your parenthetical aside: we have precedent in Harmony  
(functions in blocks) for finding room to create a better standard  
where browsers do not agree, and therefore unless browser detection is  
going on, cross-platform JS on the web cannot depend on the  
intersection semantics (the empty set).

I think we should investigate breaking changes. The IE JScript  
deviations document linked from

http://wiki.ecmascript.org/doku.php?id=es3.1:es3.x_working_docs&s=jscript+deviations

contains some amazing details of IE"s for-in behavior:

* Enumerate properties on immediate prototype in reverse order (w.r.t  
the order in which they were added)

* Enumerate properties in-order on rest of the objects on the  
prototype chain

* Enumerate properties in-order on present object.

Reverse insertion order on the immediate prototype properties, not  
something other engines do.

Array element enumeration details are lacking, but again if the  
observation that array elements are almost always created in index  
order, then insertion order == index order. The exceptions may or may  
not work as expected on insertion-order-only implementations. Firefox  
3+ uses index order. We're not receiving bug reports.

There's room to find a better common semantics here, it seems to me.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Property Iteration in JSON serialization

Brendan Eich-3
In reply to this post by Brian Kardell
On Oct 14, 2009, at 8:34 PM, Brian Kardell wrote:

> Sorry... somehow Waldemar's comment got closed up in my Gmail
> conversation stack and I missed this comment...
>
> If Oliver and  Hallvord and Brendan are wrong on the idea that it is
> at least largely already a de facto standard for non-indexed
> properties then  I suppose it is a moot point...
>

Waldemar did not cite non-indexed property counter-examples to  
insertion order, and insertion order is the rule among browsers.  
However, I did just posted a reference to:

* Enumerate properties on immediate prototype in reverse order (w.r.t  
the order in which they were added)

* Enumerate properties in-order on rest of the objects on the  
prototype chain

* Enumerate properties in-order on present object.


from the first pdf link in

http://wiki.ecmascript.org/doku.php?id=es3.1:es3.x_working_docs&s=jscript+deviations

to highlight Pratap's revelation that IE JScript (at least some  
versions) use reverse-insertion order for the immediate prototype's  
enumerable properties.

But so what? Enumerable prototype properties are rare and they are  
considered bad practice. IE alone behaves in this exceptional manner  
for the direct prototype's properties. As far as I know, all other  
implementations use insertion order for non-indexed properties.

We are not going to standardize this anomaly, and cross-browser JS  
can't count on it. So we should standardize something saner, possibly  
insertion order for named properties, index order for indexed.

/be

>
>
>
>
>
> On Wed, Oct 14, 2009 at 4:24 PM, Waldemar Horwat  
> <[hidden email]> wrote:
>> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Property Iteration in JSON serialization

Maciej Stachowiak
In reply to this post by Brian Kardell

On Oct 14, 2009, at 8:34 PM, Brian Kardell wrote:

> Sorry... somehow Waldemar's comment got closed up in my Gmail
> conversation stack and I missed this comment...
>
> If Oliver and  Hallvord and Brendan are wrong on the idea that it is
> at least largely already a de facto standard for non-indexed
> properties then  I suppose it is a moot point...

Historically, the areas where JS engines in the major browsers have  
diverged on for..in enumeration order have been properties with index-
like names, and properties on the prototype chain. I made a test case  
to study some of these differences.

Current JavaScriptCore and SpiderMonkey seem to get identical results  
on this, other browsers all have slight variations:

Here are some of the variations I found:

== Index properties on non-arrays ==
JSC/Safari - insertion order
SpiderMonkey/Firefox - insertion order
Futhark/Opera - insertion order
V8/Chrome - numeric sorted order
JScript/IE - insertion order

== Index properties on arrays ==
JSC/Safari - numeric sorted order
SpiderMonkey/Firefox - numeric sorted order
Futhark/Opera - insertion order
V8/Chrome - numeric sorted order
JScript/IE - insertion order

== Objects with enumerable properties in the prototype chain ==
JSC/Safari - own properties in insertion order, followed by prototype  
properties from most direct prototype to least direct (each prototypes  
properties in insertion ordr)
SpiderMonkey/Firefox - same
Futhark/Opera - same
V8/Chrome - properties are re-ordered, even own properties, but I  
don't understand the rule(*)
JScript/IE - prototype properties are reported before own properties;  
own properties are in order, but properties on every other prototype  
are reversed (I think?)


(*) - If you use constructor functions to make an object with  
properties named (x, y, z) added in that order, with a prototype that  
has properties (a, b, c), and in turn has a prototype with properties  
(q, r, s), JSC and SpiderMonkey report "x y z a b c q r s" but V8  
gives "x z y a c b q r s". I'm not sure what rule would give that  
output. I'm not even sure if this behavior is intentional or a bug.


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.

All the browsers besides Chrome also seem to report index-like  
properties on arrays in insertion order, and report own properties in  
insertion order even when there are enumerable prototype properties  
(though the prototype properties may be before or after). Perhaps  
somewhat self-servingly, I think the Safari/Firefox behavior is the  
most sensible overall, so if we ever fully standardize the enumeration  
order, that is what I would suggest.


Here's my test case if you want to try for yourself:




Regards,
Macej


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

for-in.html (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Property Iteration in JSON serialization

Maciej Stachowiak

On Oct 14, 2009, at 10:47 PM, Maciej Stachowiak wrote:

>
> (*) - If you use constructor functions to make an object with  
> properties named (x, y, z) added in that order, with a prototype  
> that has properties (a, b, c), and in turn has a prototype with  
> properties (q, r, s), JSC and SpiderMonkey report "x y z a b c q r  
> s" but V8 gives "x z y a c b q r s". I'm not sure what rule would  
> give that output. I'm not even sure if this behavior is intentional  
> or a bug.

Correction: on further testing, it appears that Chrome's ordering  
anomaly is for own properties added by a constructor function, whether  
or not there's a prototype with enumerable properties. Chrome reports  
"a c b" for the following, whereas other browser which reports "a b c".

<pre>
<script>
function Construct()
{
     this.a = "a";
     this.b = "b";
     this.c = "c";
}

var constrObj = new Construct();

function printProperties(description, o) {
     document.write(description + ":");
     for (var pname in o) {
         document.write(" " + pname);
     }
     document.write("\n");
}

printProperties("constructed object", constrObj);
</script>
</pre>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Property Iteration in JSON serialization

Brian Kardell
For even more fun try out the code below which has mixed content and
still appears to function (surprisingly) the same in FF 3.5/Safari4
(OSX) and IE8 (XP) -- but seems to order the keys differently in
Chrome 3 - though seemingly still as explained earlier (except that
the negative index is last??):

function Construct(){
    this["-1"] = "holy cow";  //This surprises me"
    this.a = "a";
    this[1] = "what";
    this.b = "b";
    this["1"] = "the";
    this["2"] = "heck";
    this.c = "c";
}

var constrObj = new Construct();
constrObj["3"] = "I don't even know what this is supposed to be!";

function printProperties(description, o) {
    var str = "";
    str += description;
    for (var pname in o) {
        str += " " + pname + " - " + o[pname] + "\n";
    }
    alert(str);
    alert(o[1]);
    alert(o[-1]);
}

printProperties("constructed object:\n", constrObj);




On Wed, Oct 14, 2009 at 10:53 PM, Maciej Stachowiak <[hidden email]> wrote:

>
> On Oct 14, 2009, at 10:47 PM, Maciej Stachowiak wrote:
>
>>
>> (*) - If you use constructor functions to make an object with properties
>> named (x, y, z) added in that order, with a prototype that has properties
>> (a, b, c), and in turn has a prototype with properties (q, r, s), JSC and
>> SpiderMonkey report "x y z a b c q r s" but V8 gives "x z y a c b q r s".
>> I'm not sure what rule would give that output. I'm not even sure if this
>> behavior is intentional or a bug.
>
> Correction: on further testing, it appears that Chrome's ordering anomaly is
> for own properties added by a constructor function, whether or not there's a
> prototype with enumerable properties. Chrome reports "a c b" for the
> following, whereas other browser which reports "a b c".
>
> <pre>
> <script>
> function Construct()
> {
>    this.a = "a";
>    this.b = "b";
>    this.c = "c";
> }
>
> var constrObj = new Construct();
>
> function printProperties(description, o) {
>    document.write(description + ":");
>    for (var pname in o) {
>        document.write(" " + pname);
>    }
>    document.write("\n");
> }
>
> printProperties("constructed object", constrObj);
> </script>
> </pre>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Property Iteration in JSON serialization

Brian Kardell
In reply to this post by Brendan Eich-3
On something saner:  It does seem quite rational - and as you point
out, it's bad practice and should be rarely used... It also stands to
reason that it _is_ rarely used as IE still maintains the dominant
share and does it differently, yet no one seems to be screaming about
it... unlike the general rule regarding non-indexed (vanilla)
properties which Opera found they had to change just in order to keep
things running.



On Wed, Oct 14, 2009 at 10:31 PM, Brendan Eich <[hidden email]> wrote:

> On Oct 14, 2009, at 8:34 PM, Brian Kardell wrote:
>
>> Sorry... somehow Waldemar's comment got closed up in my Gmail
>> conversation stack and I missed this comment...
>>
>> If Oliver and  Hallvord and Brendan are wrong on the idea that it is
>> at least largely already a de facto standard for non-indexed
>> properties then  I suppose it is a moot point...
>>
>
> Waldemar did not cite non-indexed property counter-examples to insertion
> order, and insertion order is the rule among browsers. However, I did just
> posted a reference to:
>
> * Enumerate properties on immediate prototype in reverse order (w.r.t the
> order in which they were added)
>
> * Enumerate properties in-order on rest of the objects on the prototype
> chain
>
> * Enumerate properties in-order on present object.
>
>
> from the first pdf link in
>
> http://wiki.ecmascript.org/doku.php?id=es3.1:es3.x_working_docs&s=jscript+deviations
>
> to highlight Pratap's revelation that IE JScript (at least some versions)
> use reverse-insertion order for the immediate prototype's enumerable
> properties.
>
> But so what? Enumerable prototype properties are rare and they are
> considered bad practice. IE alone behaves in this exceptional manner for the
> direct prototype's properties. As far as I know, all other implementations
> use insertion order for non-indexed properties.
>
> We are not going to standardize this anomaly, and cross-browser JS can't
> count on it. So we should standardize something saner, possibly insertion
> order for named properties, index order for indexed.
>
> /be
>
>>
>>
>>
>>
>>
>> On Wed, Oct 14, 2009 at 4:24 PM, Waldemar Horwat <[hidden email]>
>> wrote:
>>>
>>> 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
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Property Iteration in JSON serialization

Allen Wirfs-Brock-2
In reply to this post by Brendan Eich-3
I'm not particularly defending IE's legacy enumeration order, we were initially on board with ES5 adopting the de facto order used by other browsers.  My recollection is that the decision to table defining a strict enumeration order for ES5 was made after we discovered that Opera for its optimized arrays did not follow the expected order https://mail.mozilla.org/pipermail/es5-discuss/2008-May/001286.html and https://mail.mozilla.org/pipermail/es5-discuss/2008-June/001304.html and many other messages in that thread.

We definitely should try to define a rational enumeration order.  It is a secondary issues as to whether we impose it as a potentially breaking change upon the existing for-in or introduce it via new syntax.  I think the second alterative is an approach we should at least consider not just in this situation but in all similar situations.  Sometimes it will make sense and other times it won't.

Allen


>-----Original Message-----
>From: Brendan Eich [mailto:[hidden email]]
>Sent: Wednesday, October 14, 2009 10:26 PM
>To: Allen Wirfs-Brock
>Cc: Mike Shaver; Waldemar Horwat; es-discuss
>Subject: Re: Property Iteration in JSON serialization
>
>On Oct 14, 2009, at 7:01 PM, Allen Wirfs-Brock wrote:
>
>> Similarly, rather than trying to fully specifying for-in enumeration
>> order (and invariably causing potentially breaking changes for some
>> implementations)
>
>I'm focusing on your parenthetical aside: we have precedent in Harmony
>(functions in blocks) for finding room to create a better standard
>where browsers do not agree, and therefore unless browser detection is
>going on, cross-platform JS on the web cannot depend on the
>intersection semantics (the empty set).
>
>I think we should investigate breaking changes. The IE JScript
>deviations document linked from
>
>http://wiki.ecmascript.org/doku.php?id=es3.1:es3.x_working_docs&s=jscrip
>t+deviations
>
>contains some amazing details of IE"s for-in behavior:
>
>* Enumerate properties on immediate prototype in reverse order (w.r.t
>the order in which they were added)
>
>* Enumerate properties in-order on rest of the objects on the
>prototype chain
>
>* Enumerate properties in-order on present object.
>
>Reverse insertion order on the immediate prototype properties, not
>something other engines do.
>
>Array element enumeration details are lacking, but again if the
>observation that array elements are almost always created in index
>order, then insertion order == index order. The exceptions may or may
>not work as expected on insertion-order-only implementations. Firefox
>3+ uses index order. We're not receiving bug reports.
>
>There's room to find a better common semantics here, it seems to me.
>
>/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Property Iteration in JSON serialization

Maciej Stachowiak

On Oct 15, 2009, at 10:23 AM, Allen Wirfs-Brock wrote:

> I'm not particularly defending IE's legacy enumeration order, we  
> were initially on board with ES5 adopting the de facto order used by  
> other browsers.  My recollection is that the decision to table  
> defining a strict enumeration order for ES5 was made after we  
> discovered that Opera for its optimized arrays did not follow the  
> expected order https://mail.mozilla.org/pipermail/es5-discuss/2008-May/001286.html 
>  and https://mail.mozilla.org/pipermail/es5-discuss/2008-June/001304.html 
>  and many other messages in that thread.

I think my email on this thread summarized the current areas of  
divergent behavior (complete with test cases). It basically amounts to:

- Different behavior for index-like properties (either insertion order  
or numeric order, in some implementations different between arrays and  
non-arrays). Firefox and Safari seem to agree, no other two browsers  
agree with each other.
- Different behavior for prototype properties in IE.
- Properties created by a constructor are enumerated in arbitrary  
order, in Chrome only (I assume this is a bug, so I'm going to ignore  
it in the discussion below).

> We definitely should try to define a rational enumeration order.  It  
> is a secondary issues as to whether we impose it as a potentially  
> breaking change upon the existing for-in or introduce it via new  
> syntax.  I think the second alterative is an approach we should at  
> least consider not just in this situation but in all similar  
> situations.  Sometimes it will make sense and other times it won't.

Even if we don't fully specify the order for for..in, there is a  
significant intersection of behavior that Web content depends on,  
namely that own properties which don't look like indices get  
enumerated in insertion order. Even if we don't fully specify the  
order, we should at least specify that much in a future ES spec.

I also think removing the differences in handling of index properties  
and prototype properties is unlikely to be a breaking change for  
anyone, so I believe we could fully specify the order in a future ES  
spec.

Regards,
Maciej

>
> Allen
>
>
>> -----Original Message-----
>> From: Brendan Eich [mailto:[hidden email]]
>> Sent: Wednesday, October 14, 2009 10:26 PM
>> To: Allen Wirfs-Brock
>> Cc: Mike Shaver; Waldemar Horwat; es-discuss
>> Subject: Re: Property Iteration in JSON serialization
>>
>> On Oct 14, 2009, at 7:01 PM, Allen Wirfs-Brock wrote:
>>
>>> Similarly, rather than trying to fully specifying for-in enumeration
>>> order (and invariably causing potentially breaking changes for some
>>> implementations)
>>
>> I'm focusing on your parenthetical aside: we have precedent in  
>> Harmony
>> (functions in blocks) for finding room to create a better standard
>> where browsers do not agree, and therefore unless browser detection  
>> is
>> going on, cross-platform JS on the web cannot depend on the
>> intersection semantics (the empty set).
>>
>> I think we should investigate breaking changes. The IE JScript
>> deviations document linked from
>>
>> http://wiki.ecmascript.org/doku.php?id=es3.1:es3.x_working_docs&s=jscrip
>> t+deviations
>>
>> contains some amazing details of IE"s for-in behavior:
>>
>> * Enumerate properties on immediate prototype in reverse order (w.r.t
>> the order in which they were added)
>>
>> * Enumerate properties in-order on rest of the objects on the
>> prototype chain
>>
>> * Enumerate properties in-order on present object.
>>
>> Reverse insertion order on the immediate prototype properties, not
>> something other engines do.
>>
>> Array element enumeration details are lacking, but again if the
>> observation that array elements are almost always created in index
>> order, then insertion order == index order. The exceptions may or may
>> not work as expected on insertion-order-only implementations. Firefox
>> 3+ uses index order. We're not receiving bug reports.
>>
>> There's room to find a better common semantics here, it seems to me.
>>
>> /be
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Property Iteration in JSON serialization

liorean
If I recall correct, Opera has a weird behaviour where it follows a
certain predictable ordering - unless you're deleting/removing a
property (or use prototype functions that do that in their operation)
on an object, which radically changes the sorting order in a way that
is only predictable with knowledge of how the object looked at the
time of the deleting/removing of a property. IIRC the properties
present on the object before the delete got shuffled to the end of the
enumeration order.
--
David "liorean" Andersson
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12