Dean Landolt wrote:
On Tue, Oct 23, 2012 at 11:53 AM, Brendan Eich <[email protected]
<mailto:[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/ near
the bottom.
By contrast, @parent would be no better in function (ignore form)
from __proto__.
Isn't there some value in stratification?
You mean using a symbol not a string? "Stratification" usual means a
meta-layer API not defined in a base-level object, not a name-kind change.
Wouldn't this make it possible to move __proto__ back to a
non-normative note, so that one day,
We don't have plans to remove things. It's hard to make such on the web.
We could hope, but it's not really relevant.
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.
1. No, we rejected a static method because it would have to be neutered
in SES environments but those may want to mash up within one realm, so
Object.foo is a pigeon-hole problem and neutering breaks valid users in
the non-SES code.
2. What's more, having two things forever instead of three hardly beats
having one thing, unless you over-weight the cost of dunder-proto. A
rose by any other name...
You say "nicer synomym for the very long run", but in the *very* long
run why couldn't it be a true replacement?
Because we cannot and do not plan on removing anything. It's not
practical on the web. It might be possible, who knows? But in realistic,
predictable, and foreseeable terms, all we are doing is adding
complexity and redundancy (ignoring the undesirable point (1) above).
The web isn't pretty. It's not the Mona Lisa. But (as Anders patiently
points out in the GOTO interview mentioned recently) all practical,
mature languages have quirks and ugly spots.
Not to defend JS too much, it could be prettier -- but this thread won't
actually achieve anything as far as the eye can see. Do rouge and
lipstick make the wart of __proto__ into a beauty spot? Only if you turn
a blind eye.
Considering all the opinions around accessor usage in the standard,
I'd think eliminating this dunder-wart would be a pretty nice
aesthetic win.
Not sure what you mean. I'm ok with either magic data or accessor with
poisoned reflection, and either is sufficiently compatible. Doesn't
affect anything in this thread.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
