B.3.1 The __proto__ pseudo property

Jeff Walden jwalden+es at MIT.EDU
Wed May 8 15:21:41 PDT 2013

On 05/08/2013 01:58 PM, Brendan Eich wrote:
> 1. Dumping stuff into Annex B to show disdain. This is pride, bad for the soul.

"Pride" doesn't seem like a reason one way or the other, to me.  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.  Some will, even still, perhaps just out of obstinacy ("pride", 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.

> 2. More important: people port code from the web. In what future super-web will we start fresh?

How much code gets ported from the web?  Most libraries I can think of are pretty intricately tied to the event loop, the DOM, browser-isms like window.atob/btoa, and any number of other things.  The true reason is that new environments may spin up that don't care about code ported from the web.  SpiderMonkey even supports this with the __proto__ feature-disabling macro.  Supposing v8 didn't have __proto__, would Node have been less successful?  I can't see __proto__ as a dealbreaker for the success or failure of JS embeddings.  Or Object.setPrototypeOf, either, for that matter.

I'd Annex-B the whole lot of this, if I were putting it anywhere in the spec.  (Probably even the object-literal and [[SetInheritance]] bits of it, too, although these would be somewhat awkward out of line like that.)


More information about the es-discuss mailing list