Comments on Meeting Notes

Herby Vojčík herby at mailbox.sk
Tue Dec 4 13:12:03 PST 2012



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).


More information about the es-discuss mailing list