Re: Avoiding overloading the term “prototype”

Dean Landolt dean at
Tue Oct 23 09:33:48 PDT 2012

On Tue, Oct 23, 2012 at 11:53 AM, Brendan Eich <brendan at> wrote:

> 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
>**10/harmony-of-dreams-come-**true/<>near the bottom.
> By contrast, @parent would be no better in function (ignore form) from
> __proto__.

Isn't there some value in stratification? Wouldn't this make it possible to
move __proto__ back to a non-normative note, so that one day, maybe...just
maybe, it can be forgotten altogether? I an Object.setPrototypeOf API has
been suggested before -- but if it were specified with @prototype then all
legacy uses of __proto__ could be shimmed inside this official API
surface. You say "nicer synomym for the very long run", but in the
*very*long run why couldn't it be a true replacement?

Considering all the opinions around accessor usage in the standard, I'd
think eliminating this dunder-wart would be a pretty nice aesthetic win. I
know __proto__ isn't going anywhere for a long time, but does it really
have to be standardized, especially when there's more "pure" alternative?

>  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.
> /be
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list