Re: variable declarations shadowing named properties on window

Travis Leithead:
> 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.

s/aesthetic/sensibleness/ if you want.  And you say "just to satisfy 
this shadowing requirement" but this seems like an important thing to 
get right.

But all right, I'm sympathetic to people expecting window.__proto__ to 
be Window.prototype (and my Code Search the other week (RIP) did reveal 
some instances of this).

Having the named properties live elsewhere does effectively make 
[ReplaceableNamedProperties] usable only for singletons like Window 
(since otherwise it would be weird if there were multiple instances with 
an object in their proto chain that returns named properties for all 
instances at once), but that's probably not a big deal; we shouldn't be 
encouraging spec writers to use [ReplaceableNamedProperties] anyway.

(Unless... we make the descriptors returned for these named properties 
be accessor properties, whose getters could look at the this value to 
determine whether to return a particular named property value or 
undefined instead.  That might be a bit too crazy though.)

Would the lack of a constructor property on the named properties object 
really break sites?  window.__proto__.__proto__.constructor would 
evaluate to window.__proto__.__proto__.__proto__.constructor == 
Object.prototype.constructor == Object.  Of course you could notice with 
Object.getOwnPropertyDescriptor that there's no constructor property 
there, but I doubt sites are doing that.

Having the object stringify to "[object WindowNamedProperties]" seems a 
sensible choice as anything.

But to be honest, I'm not strongly attached to this over your suggestion 
of putting the properties on Window.prototype itself, if we are not 
having a separate named properties object exist as window.__proto__. 
Boris, apart from being different from what Gecko does now, do you 
forsee any problems with sticking the named properties on Window.protoype?

Received on Monday, 23 January 2012 01:11:40 UTC