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.
David
[1] http://wiki.ecmascript.org/doku.php?id=strawman:enumeration
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
