Avoiding overloading the term “prototype”

Herby Vojčík herby at mailbox.sk
Tue Oct 23 07:40:14 PDT 2012

Brendan Eich wrote:
> Herby Vojčík wrote:
>> By the way, let deprecate (that is, recommend not to use) __proto__
>> and introduce @parent (or other term) instead, while both having the
>> same behaviour.
> We could do this, given symbols, but would it help? New code could use
> it in the next several years only with an ES6->ES5 compiler and ignoring
> IE on desktop; this is a real possibility for "mobile developers",
> self-defined. But developers could just as well use __proto__ and
> probably will skip the compiler without strong need for other ES6 features.
> This means we're adding a nicer synonym for the very long run. Which
> means two things, more total surface syntax, more "cruft" from certain
> points of view. Is it worth it?

I think 'cruft' is too strong. There will be two things that do the same 
thing, one 'legacy', one new. Though I can not give an example, I have 
the impression things like that happens (use X, there is Y for 
compatibility, for it is not endorsed now...) often.

Having things in 'less than happy' state in more details simply breaks 
the (possible good) progress. At least my experience is, that if you 
refactor details of this kind (though they may seem formal), the 'flow' 
is freed. So if change of this kind is accompanied with terms cleaning 
as well, it may move the whole thing on to new quality.

But. I am not the one responsible, I do not see all the differing 

> /be


More information about the es-discuss mailing list