Nailing object property order

Tom Schuster tom at schuster.me
Sat Apr 18 11:01:48 UTC 2015


Thanks Juriy,

for writing a test for this. The problem in SpiderMonkey/Firefox is the
line

Object.defineProperty(obj, '4', { value: true, enumerable: true });

which defines a non-writable/non-configurable element. We don't store those
with "normal" elements and thus they fall into the insertion order case. We
can probably fix this by actually reordering them when somebody calls
Object.keys or such.

Btw I think we would have an other bug, the spec defines how to treat
"integer index", but we will only do this order for non-sparse "array
index" elements, i.e. ~< 2^32-1.

On Fri, Apr 17, 2015 at 7:36 PM, Juriy Zaytsev <kangax at gmail.com> wrote:

> fwiw, tests for enumeration order now in compat table —
> https://github.com/kangax/compat-table/commit/a267f2233ce3b25dfbee876f4a4786ad85b31049
>
> Results — https://kangax.github.io/compat-table/es6/#own_property_order
>
> --
> kangax
>
> On Thu, Apr 16, 2015 at 8:37 PM, Brendan Eich <brendan at mozilla.org> wrote:
>
>> Also, it's too late. Engines are converging, inter-operation pressure
>> points in one direction only: greater convergence and standardization.
>>
>> It's true engines are not converging on the ancient insertion order, and
>> that caused some interop stress, but we are over that hump now. See
>> https://code.google.com/p/v8/issues/detail?id=164&can=1&q=enumeration&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary%20HW%20OS%20Area%20Stars
>> (a long, and long-resolved, V8 issue).
>>
>> Bergi's frustration is understandable. Leaving things unspecified for too
>> long was a failure on our part in tending the spec, or a trade-off (we had
>> other things to do ;-). All water under the bridge, but we're not stepping
>> back to unspecified behavior. Because engines aren't, because developers do
>> not want.
>>
>> And agree with Mark: POITROAE.
>>
>> /be
>>
>> Mark S. Miller wrote:
>>
>>> Developer productivity > hypothetical minor performance gains.
>>>
>>> +1 to all steps to make the specified behavior more deterministic,
>>> including this one.
>>>
>>>
>>> On Thu, Apr 16, 2015 at 10:07 AM, liorean <liorean at gmail.com <mailto:
>>> liorean at gmail.com>> wrote:
>>>
>>>     I'm very much opposed to locking this down for general objects
>>> because
>>>     it locks the implementation choices for generic objects down. What if
>>>     the engine backing implementation was, say, some variation of a trie
>>>     for instance? It cannot really be done today without adding
>>> extraneous
>>>     data into the structure, because lookup in that case happens on a
>>>     character by character basis, not on a whole string basis, so
>>>     properties that use common prefixes would always end up adjacent and
>>>     even if the keys weren't inserted in order by bit patterns into the
>>>     trie as most implementations do, they would still be grouped by
>>> common
>>>     prefix.
>>>     --
>>>     David "liorean" Andersson
>>>     _______________________________________________
>>>     es-discuss mailing list
>>>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>>     https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>>
>>>
>>> --
>>>     Cheers,
>>>     --MarkM
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150418/9b174eee/attachment.html>


More information about the es-discuss mailing list