On Tue, Oct 23, 2012 at 11:53 AM, Brendan Eich <[email protected]> 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 > [email protected] > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
