B.3.1 The __proto__ pseudo property
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?
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?
More information about the es-discuss