(I meant "getOwnPropertyDescriptor" instead of "defineProperty" in
that last paragraph.)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I was the one who authored that commit, but thanks.
Incidentally, I left off checks for the following behaviour which also
uses the OwnPropertyKeys ordering, on the basis that they're generally
too obscure to manifest in usual programs (but then, what do I know?):
* Object.freeze/Object.seal/Obj
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
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 wrote:
> Also, it's to
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
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 wrote:
> I'm very much opposed to locking this down for general objects because
> it locks the impleme
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 stru
Scott Sauyet schrieb:
> Do you see good reasons *not* to do it, or are you just wondering if
> there actually were pros to this?
Oh, I can see the use cases (you've given a good example, thanks).
Everyone needs ordered dictionaries/maps once in a while. Maybe even
sortable ones, including `ins
I don't have pointers to other es-discuss threads where this was
mentioned, but I do have a reason of my own for wanting this.
I started and help maintain Ramda [1], a functional programming
library for ES. It is a collection of utility functions similar in
scope to Underscore or lodash, although
Tab Atkins Jr. schrieb:
On Wed, Apr 15, 2015 at 6:39 PM, wrote:
What was the motivation to pin these down in ES6?
Because, for objects at least, all implementations used approximately
the same order (matching the current spec), and lots of code was
inadvertently written that depended on th
For what it's worth, forcing an enumeration order does make polyfilling
harder, assuming there's an engine out there that *doesn't* already use
that ordering.
On Wed, Apr 15, 2015 at 6:39 PM, wrote:
> Hello!
> Why does ES6 specify the order of keys in objects, maps and sets?
> Specifically secti
On Wed, Apr 15, 2015 at 6:39 PM, wrote:
> Hello!
> Why does ES6 specify the order of keys in objects, maps and sets?
> Specifically section 9.1.12 [[OwnPropertyKeys]] says the result list must be
> "integer indices in ascending numeric, then strings in property creation
> order, then symbols in
Hello!
Why does ES6 specify the order of keys in objects, maps and sets?
Specifically section 9.1.12 [[OwnPropertyKeys]] says the result list must be
"integer indices in ascending numeric, then strings in property creation order,
then symbols in property creation order".
Similarly, 23.1.3.5 Map.p
13 matches
Mail list logo
