Property Iteration in JSON serialization

Brian Kardell 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
things running.



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
> 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 <waldemar at google.com>
>> 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
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
>


More information about the es-discuss mailing list