Brendan Eich wrote:
Herby Vojčík wrote:
recommend a more conservative approach for ES6: use the plain string
"iterator" as the protocol hook. Once the syntactic issues have been
I'd say not "iterator". This is a special identifier, so to speak
"instead-of-symbol-internal-name", so I would go for __iterator__.
Same for other few examples which may have benefited from symbols but
cannot.
TC39 probably will barf, but you make a good point -- so good it's what
I implemented in JS1.7 and up in SpiderMonkey.
I didn't know, really. :-)
It would create consistent __legacy__ realm where each member should
be obsoleted by evangelizing the right way once it appears (__proto__
won't have one, it is too stuck; __{define|lookup}{Getter|Setter}__
already have the right way; it can be same for __iterator__,
__create__, __hasInstance__ etc.).
We hope to skip this legacy and leave it in the multiverse of
alternative realities. Can we do it? If not now, why do you think we
could do it later, when the dunder-names are sucking all the oxygen out
of the "use symbols" room?
I am convinced it is doable (to have __legacy__ names but move to use
the better way once it is present) with the example of __defineGetter__
& Co. I confess I don't know how this is in the wild, just me being here
makes me a kind of early adopter with bias for using the new/right way,
but I feel those (__defineGetter__ and company) are of little use now
and the world successfully moved to Object.defineProperty / {get,set}
x() in literals. So why this wouldn't be possible for others?
/be
Herby
P.S.: And even __proto__ could be changed to use @parent or similar
syntax later. I already proposed it here on the list a few weeks ago.
Every __legacy__ could have its note in spec, saying what should be used
instead. And just wait until it catches up (while pushing it constantly).
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
