Property Iteration in JSON serialization
bkardell at gmail.com
Wed Oct 14 23:29:24 PDT 2009
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
On Wed, Oct 14, 2009 at 10:31 PM, Brendan Eich <brendan at mozilla.com> 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
> * Enumerate properties in-order on present object.
> from the first pdf link in
> to highlight Pratap's revelation that IE JScript (at least some versions)
> use reverse-insertion order for the immediate prototype's enumerable
> 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.
>> On Wed, Oct 14, 2009 at 4:24 PM, Waldemar Horwat <waldemar at google.com>
>>> 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. 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
>>> would likely break compatibility.
>> es-discuss mailing list
>> es-discuss at mozilla.org
More information about the es-discuss