Avoiding overloading the term “prototype”

Brendan Eich brendan at mozilla.org
Tue Oct 23 11:14:39 PDT 2012


Dean Landolt wrote:
> On Tue, Oct 23, 2012 at 11:53 AM, Brendan Eich <brendan at mozilla.org 
> <mailto: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/ 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


More information about the es-discuss mailing list