Avoiding overloading the term “prototype”

Brendan Eich brendan at mozilla.org
Tue Oct 23 08:53:50 PDT 2012

Herby Vojčík wrote:
> 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.

Number.isNaN adds value, by not coercing non-number arguments to number, 
compared to isNaN. Ditto similar innovations, see 
https://brendaneich.com/2012/10/harmony-of-dreams-come-true/ near the 

By contrast, @parent would be no better in function (ignore form) from 

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

I'm in the same boat. I see the attraction, very long run. Perhaps 
others will weigh in.


More information about the es-discuss mailing list