W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2012

RE: variable declarations shadowing named properties on window

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>
Message-ID: <9768D477C67135458BF978A45BCF9B38381E8F7B@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
>-----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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:05 UTC