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, <a.d.be...@web.de> 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 property creation order".
> Similarly, 23.1.3.5 Map.prototype.forEach and 23.2.3.6
> Set.prototype.forEach use the "original insertion order" of keys for their
> callbacks, and also their respective @@iterators use the ordered "entries"
> lists.
>
> What was the motivation to pin these down in ES6?
>
> In ES5, objects were intrinsically unordered. ES3 was explicit about that
> an "object is an unordered collection of properties", the same thing is
> still in JSON for example, where objects are defined as "unordered set of
> name/value pairs".
> ES5 did only specify that for-in and Object.keys should use the same order
> ("if an implementation specifies one" at all). ES6 didn't even tighten
> this, it only describes it with a new [[enumerate]]-mechanism.
>
> But would it be reasonable to expect that every implementation will use
> the same order in for-in loops and Object.keys as in
> Object.getOwnPropertyNames/Symbols property listings? I can't imagine how a
> different ordering would be helpful for an implementation.
>
> To me, a fixed order sounds like an arbitrary restriction. There would
> always be a little overhead in remembering the order, and it would prevent
> optimisations that could treat {x:1, y:2} and {y:2, x:1} as having the same
> structure.
> And while ordered maps/sets are a good thing, they are not really sortable
> by ones own criteria. If I wanted to insert a value at a certain position,
> I'd need to first clear the map/set and then re-append all entries in the
> desired order. There will surely be people who want to use maps/sets like
> that, and I wonder whether it was deliberately made that
> complicated/inperformant to support this use case.
>
> Does anyone share my concerns? The only thing I've found online was
> "deterministic enumeration" <
> https://mail.mozilla.org/pipermail/es-discuss/2013-April/030204.html>,
> pointers to other discussions are welcome.
>
> Bergi
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
