B.3.1 The __proto__ pseudo property
jwalden+es at MIT.EDU
Thu May 9 14:36:57 PDT 2013
On 05/09/2013 10:12 AM, Brendan Eich wrote:
> Adding an equivalent to the main spec does not cordon off the mis-performing (non-performant?) functionality.
I may have misread, but I had thought there was argument to put Object.setPrototypeOf in Annex B as well. If it's added, that seems like the right place to me. There are somewhat orthogonal concerns here, for __proto__ and an Object.* method. Special-form badness is only in __proto__ the syntax. Prototype mutation after creation, with its erratic performance destabilization, and the impact upon proxies and [[SetInheritance]], is in __proto__ the property and an Object.*. Both aspects raise concerns of varying degree for developers.
> 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?
> 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?
Simply this: don't make ad-hoc inheritance relations where Object.create doesn't fit. Prototype mutation is extra expressiveness. But it is not *necessary* expressiveness, to write useful programs. There's an incredibly rich set of programs that can be written (have been written) without prototype mutation. I don't think it adds so much value to mandate it for every single embedding, considering its issues. Obviously you disagree to some degree. I suspect we'll have to leave it at that.
It's worth reiterating that Annex B would be better for all of this not for mobile or non-mobile web (although I don't think there's anything different about mobile and non-mobile with respect to __proto__'s utility -- its utility on mobile is solely a matter of mobile being dominated by engines with __proto__). It's to not penalize embeddings working on a blank slate.
More information about the es-discuss