- From: Travis Leithead <travis.leithead@microsoft.com>
- Date: Mon, 9 Jan 2012 19:39:39 +0000
- To: Cameron McCormack <cam@mcc.id.au>
- CC: Boris Zbarsky <bzbarsky@MIT.EDU>, Allen Wirfs-Brock <allen@wirfs-brock.com>, Ojan Vafai <ojan@chromium.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Ian Hickson <ian@hixie.ch>, Jeff Walden <jwalden@mit.edu>
>-----Original Message-----
>From: Cameron McCormack [mailto:cam@mcc.id.au]
>
>1. [Object.prototype] <- [named props] <- [Window.prototype] <- [window]
>2. [Object.prototype] <- [Window.prototype] <- [named props] <- [window]
>3. [Object.prototype] <- [Window.prototype + named props] <- [window]
>
>I'm advocating for (2) over (3) for the same reasons as over (1) -- it
>seems odd to me to put instance specific properties on objects in the
>prototype chain that multiple instances would inherit from. (And yes, I
>know windows are singletons here -- it's more of an aesthetic concern.)
>
>Are you concerned about web compatibility issues of having
>Object.getPrototypeOf(window) not being Window.prototype? Or something
>else?
I'm a _little_ concerned about web compat on this, since we know a few frameworks out there mess with window.__proto__. I'm also trying to avoid making a major change ("major" to me is adding a new user-visible object in Window's prototype chain, just to satisfy this shadowing requirement) in a non-trivial integration point between Trident and our script engine. What would this new object toString()? It would likely not have a .constructor property which could break some sites.. There's a lot of other things to consider for an otherwise aesthetic concern.
Received on Monday, 9 January 2012 19:57:55 UTC