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

David Bruant bruant.d at gmail.com
Wed Nov 21 13:43:18 PST 2012

Le 21/11/2012 21:13, Tom Van Cutsem a écrit :
> 2012/11/21 David Bruant <bruant.d at gmail.com <mailto:bruant.d at gmail.com>>
>     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)
> Even disregarding the proxy whitelist hassle, let's not go there. 
> Making all the well-known unique symbols, like @iterator, private just 
> so they don't appear in Object.getOwnPropertyNames feels silly to me. 
> We have the distinction between unique and private symbols precisely 
> because we've identified a need for symbols that need to be unique but 
> not necessarily private!
Rest assured that it doesn't make me happy to propose this idea, but it 
seems worthwhile to explore.

Allen's latest point about backward compat makes me feel that it may not 
be that big of a problem ("Note that even in legacy code, if a gOPN 
symbol  valued element is used in any context that requires a property 
key, things will still work fine.  It is only explicitly doing string 
manipulation on a gOPN element that would cause trouble. For example, 
trying to string prefix every element a list of own property names.")
I guess only user testing could tell.
If absolutely necessary, it may not be absurd to have the following: 
string + unique name = new unique name.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121121/be89b875/attachment.html>

More information about the es-discuss mailing list