Re: Avoiding overloading the term “prototype”

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


On Tue, Oct 23, 2012 at 11:53 AM, Brendan Eich <brendan at mozilla.org> 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
> https://brendaneich.com/2012/**10/harmony-of-dreams-come-**true/<https://brendaneich.com/2012/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 mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121023/92a71be3/attachment.html>


More information about the es-discuss mailing list