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
bottom.
By contrast, @parent would be no better in function (ignore form) from
__proto__.
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
