737198 - Property descriptor fields ordered differently than expected

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[André Bargull [:anba]]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120312181643

Steps to reproduce:

---
js> Object.keys(Object.getOwnPropertyDescriptor(Object.defineProperty({}, "foo", {}), "foo"))
["configurable", "enumerable", "value", "writable"]
---

I'd expected the following order: ["value", "writable", "configurable", "enumerable"]

Also see the algorithm steps in 8.10.4 [FromPropertyDescriptor]. All other engines [1] seem to agree to follow the implied order from 8.10.4. 

[1]: V8, JSC, Opera, IE10

Comment 1

[Jeff Walden [:Waldo]]

Property enumeration order is unspecified in the spec; there's no "implied order" to it.  It's at best coincidental that other engines match any particular ordering.  And, under some of the proposed proxy specifications out there, I'm not sure there even can be an implied ordering in all cases.

Comment 2

[André Bargull [:anba]]

Sure, property enumeration is unspecified, still users expect a certain order from for-in (property creation order) etc. etc. Both of us know that story all too well. 

So, if the steps in 8.10.4 are strictly followed and the result object's enumeration is also subject to creation order, the properties should be ordered as described above. And that seems to be what the other engines are currently doing. 

(To be honest, I do not depend on any specific order and therefore I am perfectly fine with closing this bug report as invalid. I've just raised the issue to inform you that there is a possible interaction problem with the other engines.)

Cheers,
André

Comment 3

[Jeff Walden [:Waldo]]

It's not entirely clear whether users really expect a certain order.  Some do, sure.  But enough that if changing ordering was a big win in performance, speed, or some other category, we wouldn't do it?  That's somewhat less clear.

For this reason I'd rather not further lock us into our current ordering (which will soon be changing somewhat, actually) whenever I can help it, because it would make such a change even harder to make.  This is one (small) place where having a different ordering helps to some small extent guard against ordering over-dependence.

Comment 4

[André Bargull [:anba]]

Sure, understood. Btw, JSC (and V8 most likely as well since they use the same tests IIRC) currently expects a specific order [1]. :(

Grepping through the mozilla sources I didn't find any property descriptor tests which expect any predefined order, though I found a little brain-oh in [2] at line 62-63.

[1] http://svn.webkit.org/repository/webkit/trunk/LayoutTests/fast/js/script-tests/Object-defineProperty.js
[2] https://raw.github.com/mozilla/mozilla-central/master/js/src/tests/js1_8_5/extensions/clone-object.js

Comment 5

[Jeff Walden [:Waldo]]

If we have tests which depend on some particular ordering (and I don't doubt we do, it's easy to be in tunnel vision mode for a particular failure mode when writing a test), we should change 'em to not depend on such an ordering.  Feel free to file bugs on any such tests you might find.  :-)