RE: variable declarations shadowing named properties on window

>-----Original Message-----
>From: Cameron McCormack [mailto:cam@mcc.id.au]
>Sent: Thursday, January 26, 2012 8:06 PM
>To: Boris Zbarsky
>Cc: Travis Leithead; Allen Wirfs-Brock; Ojan Vafai; public-script-
>coord@w3.org; Ian Hickson; Jeff Walden
>Subject: Re: variable declarations shadowing named properties on window
>
>Cameron McCormack
>>> 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.
>
>Boris Zbarsky:
>> The main use case is for global objects, so you can have undeclared
>> global variables work "right". And global objects are by assumption
>> singletons.
>
>>> 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?
>>
>> In at least Gecko I suspect this would make calling DOM methods on the
>> window slower because the normal JS optimizations would be disabled for
>> Window.prototype. We can make it work, obviously, but it would not be my
>> preferred choice.
>>
>> I can't speak to whether any other UAs would have issues with it.
>
>OK.
>
>I thought some more and in the end I think having a separate object
>would be cleaner and simpler than sticking them on Window.prototype, and
>am not too concerned with breaking sites (especially since this is where
>they live in Gecko already).  If we do run into broken sites later, we
>can try a different solution.
>
>This new object (the "named properties object") behaves like any other
>[NoInterfaceObject] prototype object.  I'll have it stringify to
>"WindowProperties" (analogously to "WindowPrototype" which is what we
>have for Window.prototype now).  It exists just above Window.prototype.
>
>http://dev.w3.org/2006/webapi/WebIDL/#NamedPropertiesObject

>http://dev.w3.org/2006/webapi/WebIDL/#named-properties-object

>
>http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.xml.diff?r1=1.453;r2=1

>.454;f=h

Thanks for closing the loop on this.

So, to clarify my understanding:
Name resolution lookup on the window/global will be:

1. window/global own props
2. WindowProperties own props
3. WindowPrototype own props
4. Object [prototype] own props
5. WindowProperties named/indexed props

Named frames are part of step 5 as I understand it.

Received on Friday, 27 January 2012 18:39:45 UTC