On 9/8/19 1:24 PM, Michael Luder-Rosefield wrote:
I'd suggest that the best way of doing this, without breaking existing
code, is to put some sugar around Maps so that they can be used in a
more Object-y way. For starters, Map literal declarations and
assignment could benefit from this.
+1
Not to mention, there is no guarantee that a persistent ID exists.
Engines have to keep an object usable as a Map key even if its address
changes (eg by a generational GC's minor/nursery collection), but there
are ways to do that without associating a permanent numeric ID with the
objects. Spidermonkey, in particular, used to rekey its internal
hashtables when objects moved in memory (essentially removing the old
address and re-inserting with the new, though in practice it was
trickier than that because we needed to prevent it from resizing the
table awkward time). It no longer does, and indeed now any object you
use as a Map key will be lazily given a unique numeric ID, but the point
is that implementing this in arbitrary engines is not necessarily as
straightforward or free as it might seem. (Though the security argument
is an even stronger counterargument.)
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
