possible excessive proxy invariants for Object.keys/etc??

David Bruant bruant.d at gmail.com
Wed Nov 21 01:55:07 PST 2012

Le 21/11/2012 01:06, Allen Wirfs-Brock a écrit :
>>>>     b) that all the elements of the result are Strings
>>>     And presumably Symbols.  We have to also accommodate Symbols, at
>>>     least for getOwnPropetyNames.  Regardless, why is this
>>>     important?  More below...
>>> Same argument as above.
>>> I recall there was some concern about symbols showing up in existing 
>>> reflection methods like Object.getOwnPropertyNames. Not sure how 
>>> that got resolved. It's basically touching upon the same issue of 
>>> whether we can change the return type of existing methods.
> I'm assuming we are excluding symbols from [[Enumerate]] and [[Keys]]
Why so? I would assume unique symbols to show up for these.

> so it is only [[GetOwnPropertyNames]] that have this concern.
and of course non-enumerable unique symbols for this operation.

For both case, I think returning unique symbols work as long as ES6 
doesn't consider that objects have built-in unique-symboled properties 
(because that could probably break existing code).

> One way or another we have to be able to reflectively get a list of 
> symbol keyed properties.
> We can either:
> 1) include them in the Object.getOwnPropertyNames result.
1bis) Make all built-in symbols (like @iterable) private
> 2) Consider getOwnPropertyNames depreciated (it actually lives 
> forever) and replace it with a new Object.getOwnPropertyKeys that 
> includes non-private Symbol keys
> 3) Keep getOwnPropertyNames as is and add Object.getOwnPropertySymbols 
> that only returns the non-private-Symbol keys.
> 1) has the greatest backward compat concerns, but is the simplest to 
> provide and for ES programmers to deal with going forward.
Since the use of Object.getOwnPropertyNames may not be widespread, maybe 
that making non-enumerable unique symbol properties could do the trick 
(as it has with new {Object, Array, etc.}.prototype additions)

1bis) If all standard built-in names are private, they're not 
enumerated, neither in for-in, Object.keys, Object.getOwnPropertyNames 
and you can have a unique name in any of these enumeration operation if 
you've added them manually, so, no backward compat (or close enough that 
it's acceptable in my opinion)
> 2) Eliminates the compat risk but creates perpetual potential for a: 
> used gOPNames when I should have used gOPK  hazard.
> 3) Eliminates the compat risk but means everybody who wants to deal 
> with all own properties have to deal with two lists of keys.  They 
> also loose relative insertion order info relating key/symbol property 
> keys.

It's a bit unfortunate to make all built-in symbols private (because 
they ought to be unique), but it feels like something acceptable.
It may induce a bit of boilerplate for proxy whitelists (because all 
built-in names like @iterable would need to be added), but a built-in 
constructor helper that would generate sets with all built-in names in 
it could solve that issue easily.


[1] http://wiki.ecmascript.org/doku.php?id=strawman:enumeration
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121121/e4d30c90/attachment-0001.html>

More information about the es-discuss mailing list