Le 21/11/2012 21:13, Tom Van Cutsem a écrit :
2012/11/21 David Bruant <[email protected] <mailto:[email protected]>>
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.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
