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, 6 Jan 2012 18:16:48 +0000
To: Boris Zbarsky <bzbarsky@MIT.EDU>, Cameron McCormack <cam@mcc.id.au>
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: <9768D477C67135458BF978A45BCF9B38381E7E42@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com>
>-----Original Message-----
>From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU]
>
>On 1/5/12 10:08 PM, Cameron McCormack wrote:
>> Only if we want to keep them on window. If we're happy to move them to
>> the prototype then we're safe, I believe.
>
>Indeed.
>
>> They can for window.foo but not for bareword lookups. window.foo will do
>> a [[Get]], and we could have that return the frame while
>> [[GetOwnProperty]] returns undefined. That breaks barewords, though,
>> which definitely do use HasBinding and so [[GetOwnProperty]] to
>> determine if the reference can be resolved or not.
>
>OK, it sounds like moving this stuff to some proto of the window is the
>way to go, unless we make some more ES spec changes of some sort.
>
>I'm perfectly happy with that, so someone else (who really wants to keep
>the GSP and whatnot on the window) would need to figure out what those
>changes should be and argue for them if they want them to happen.... ;)

Well, after pondering this for a little while, a solution that keeps 
the name resolution clean on the global object and supports shadowing
via var declarations as desired would need to come from an ES spec change.

I believe that's true because WebIDL's [[GetOwnProperty]] algorithm just
doesn't have enough context to know when an empty var declaration is being 
made vs, when a bareword lookup is happening. Due to Allen's change in [8.d.ii],
[[GetOwnProperty]] is invoked in the empty var declaration case on the global 
object. That also happens for bareword lookups on the global. Unless some 
extra state is introduced, WebIDL just won't be able to distinguish these cases
and do the right thing.

Will moving the object that supports named properties to be in the prototype chain
mess up anything else? Based on WebIDL's [DefineOwnProperty] algorithm for platform
objects, it already seems like [ReplaceableNamedProperties] and [OverrideBuiltins] 
are mutually exclusive--so there probably won't be a problem there.

It seems like moving the GSP functionality to the prototype should only happen for
[ReplaceableNamedProperties] and only for named properties (not indexed properties).

Let's at least not create a new object in the prototype chain, but rather re-use one
that is already created for this purpose, such as the Window.prototype object.
Received on Friday, 6 January 2012 18:17:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:05 UTC