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: Fri, 27 Jan 2012 18:39:07 +0000
To: Cameron McCormack <cam@mcc.id.au>, Boris Zbarsky <bzbarsky@MIT.EDU>
CC: 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: <9768D477C67135458BF978A45BCF9B3838206805@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
>-----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.
>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.




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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:46 UTC