Avoiding overloading the term “prototype”
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
>> 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
I'm in the same boat. I see the attraction, very long run. Perhaps
others will weigh in.
More information about the es-discuss