- 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>
>-----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