Subclassing built-in constructors

Brendan Eich brendan at mozilla.com
Sat May 26 13:01:06 PDT 2012


Domenic Denicola wrote:
>> -----Original Message-----
>> From: es-discuss-bounces at mozilla.org [mailto:es-discuss-
>> bounces at mozilla.org] On Behalf Of Brendan Eich
>> Sent: Saturday, May 26, 2012 15:08
>
>> New syntax may some day clean all this up but the short path wins and
>> it'll be hard to displace. Let's be realistic. I agree we should,
>> assuming classes make it, support DOM subclassing. That is good but it
>> won't relieve DOM implementors from supporting __proto__.
>
> Is there a parallel to be drawn with __(define|lookup)(Getter|Setter)__, or is __proto__ different? I quite liked Allen's blog post about why IE decided to never support them [1]. Following that reasoning seems to lead to specifying Object.setPrototypeOf as a __proto__ replacement,

No. First, you missed Mark's argument that I paraphrased against a 
per-frame (window, global context) static method, which David Bruant 
acknowledged in this thread just eight messages back:

>> Once we're at it, for the sake of completeness there is probably no 
>> harm in adding a Reflect.setPrototype at this point, is there?
>
> There is, just as there's a cost to Object.setPrototypeOf (the obvious 
> place to put it to match Object.getPrototypeOf from ES5). Mark pointed 
> out that he'd have to delete that static method too, and from every 
> frame that might run SES code. But when mashing up SES and non-SES 
> code, it would be better not to break the non-SES code by such deletion.
>
> Having only the SES environment's Object.prototype.__proto__ to delete 
> is better.
And I realize that the new hazard is not due to __proto__ in itself, but 
rather to the capability of arbitrarily changing the prototype of an 
object, so adding an Object.setPrototypeOf really is a step backward.

David

--- end quote ---

Second, Allen's rationale, made while he was at Microsoft (no comment), 
addressed particular extensions with particular arguments. We need to 
look at the cases:

* Getters and setters were more often, and better, used by the get/set 
object literal syntax. That's in ES5 without change.

* __{define,lookup}{G,S}etter__ could indeed have been standardized but 
they were not so often used as __proto__ is.

Indeed it was Microsoft's 2005-era "Atlas" AJAX knock off used by live 
maps that made use of these SpiderMonkey extensions, to dress up non-IE 
DOMs as if they were the IE DOM -- which assumes non-IE browsers have 
these __define/lookup... methods. This forced Apple and Opera to 
reverse-engineer and implement rapidly, but it did not have any effect 
on IE, of course.

Finally, everyone on TC39 wanted more than these old APIs provided. That 
led to ES5's meta-programming API under Object.

* __proto__ is widely used, especially on "the mobile web", which is not 
"the web" that many who focus on desktop see or think of when authoring. 
Thus Zepto's use of __proto__, but not of __define/lookup....

So between __proto__ being much more in demand, __define/lookup not 
being so much in demand, get/set syntax winning without change, and 
especially the "mobile web" content divergence due to WebKit, the same 
rationale for rejecting __define/lookup... did not and *does not* apply 
to rejecting __proto__.

You can't treat all __-affixed extensions the same, in short. They're 
neither all cursed nor all blessed. Usage in the market matters.

/be

>   and hoping library authors follow suit in switching to that from __proto__, just like they did for the property API.
>
> http://blogs.msdn.com/b/ie/archive/2010/08/25/chakra-interoperability-means-more-than-just-standards.aspx
>


More information about the es-discuss mailing list