B.3.1 The __proto__ pseudo property

Brendan Eich brendan at mozilla.com
Thu May 9 10:12:57 PDT 2013


Jeff Walden wrote:
> On 05/08/2013 04:10 PM, Brendan Eich wrote:
>> Why would Object.setPrototypeOf have any better perf?
>
> It wouldn't.

Then I don't know why you wrote "The reason would be to cordon off 
functionality whose mis-performance developers will not intuitively 
understand, so that they're less likely to use it" as a reason to put 
__proto__ in Annex B. Adding an equivalent to the main spec does not 
cordon off the mis-performing (non-performant?) functionality. Seems 
like one step forward, one step backward -- and a bigger spec.

>>>    developers will not intuitively understand, so that they're less likely to use it.  Some will, even still, perhaps just out of obstinacy ("pride",
>> I think you missed that that was directed at TC39ers, not developers.
>
> Some developers look at language specs, so spec position does provide meager influence that way.  Documentation authors are the likelier target.  They're going to look at specs to figure out what the methods do, to a much greater extent.  Positioning in Annex B and not in main flow sends a small message that something's different.  MDN documentation of octal syntax, for example, is only found in a deprecated/obsolete features page, for example.

I'm with you here, but then putting Object.setPrototypeOf in the main 
spec is an implicit endorsement.

>>>    even, that they hacked their way to the tiniest solution :-) ).  But some will take a second look, learn the reasons it's undesirable, and not use it.
>> And not use Object.setPrototypeOf?
>
> Yup.

Not use Object.setPrototypeOf and do what instead? If people need to 
make ad-hoc inheritance relations and Object.create doesn't fit, then what?

We're adding Object.setPrototypeOf (and __proto__, however disdained) 
for a reason. There's a use case. Its future frequency, which 
Object.setPrototypeOf might satisfy, won't go down just by putting 
__proto__ in Annex B.

>    Everyone writing for the public non-mobile web has to do it now, it's not so bad.

The non-mobile web is being eclipsed by mobile device growth. New 
content is written for smaller screens; old content lives on or dies, a 
flat to declining proposition. In the next ten years there'll be a lot 
of JS written for the web, AKA the mobile web. What should people use to 
make ad-hoc inheritance structures where Object.create does not suffice?

/be


More information about the es-discuss mailing list