Re: "var" declarations shadowing properties from Window.prototype

Jonas Sicking wrote:
> On Fri, Aug 10, 2012 at 11:17 PM, Brendan Eich<brendan@mozilla.org>  wrote:
>> Jonas Sicking wrote:
>>> One potential solution that I think we should keep in mind is to
>>> declare that WebIDL properties*on global objects*  doesn't go on the
>>>
>>> prototype chain, but rather on the global objects themselves. That
>>> seems like it'll reduce a lot of the foot guns since they will behave
>>> much more like "normal" javascript properties. I.e. we'd get a model
>>> that is much simpler for developers.
>> +1 or more.
>>
>>
>>> I feel like whatever we'll do, the interactions with 'var X' and
>>> 'function X()' will end up getting complex when there are collisions
>>> with properties on the prototype chain.
>> Yes.
>>
>> All my fault for making objects be scopes. Sorry. But we should go with it,
>> since object detection is a virtue (and var is needed for strict mode or
>> just good hygiene).
>>
>> var detect = window.mozDetect || window.webkitDetect || ... ||
>> window.detect;
>>
>> with detect a get-only accessor must work. The simplest way to ensure this
>> is to make all the window.* props "own".
>
> If we make attributes on the global live on the global itself rather
> than on the prototype chain, then "own" vs. "in" doesn't matter. I.e.
> either would work.

That's right -- then we can fix the ES5.1 erratum as SpiderMonkey and 
other engines already ahve, and stick with testing for only an "own" 
property before var decides to create a fresh property, which will 
shadow as desired (to avoid problems in implementations and probably in 
user-code with proxies on the global's prototype chain).

IOW, WebIDL changes, as you wrote. ES5.1 + the 
https://bugs.ecmascript.org/show_bug.cgi?id=78 erratum stay fixed (well, 
ES6 gets that erratum fixed; many implementations already ship it fixed).

>>> It also has the advantage that Chrome already does this so we have
>>> some basis for thinking that this could be web compatible. (Though
>>> Chrome does this for not just global objects, which is a different
>>> topic).
>> Could you say more? I can see the benefit in having an odd-man-out exception
>> for globals only. Does the "own" promotion hurt elsewhere in WebKit's DOM
>> bindings?
>
> Not sure I understand the question, so let me shoot from the hip and
> see if the answer fits :-)
>
> My point was that an odd-man-out exception for globals seems like it
> would be beneficial since it reduces complexity. And that such an
> exception hopefully is web compatible enough since it matches how
> webkit treats globals. And in fact we know that it has some
> compatibility benefits as has been mentioned above.

With you on all this. My question was about your "(Though Chrome does 
this for not just global objects, which is a different topic)"aside.

> Webkit also puts attributes on objects for non-globals, but I'm not
> promoting that behavior. Nor do I know of any benefits regarding web
> compatibility that comes with that behavior.

Ok, that's what I was getting at. It may be that this is just historical 
consistency for all objects, no global exception, but sounds like we are 
agreeing that the global object needs an exception ("own" promotion of 
attributes and methods) in WebIDL.

/be

Received on Saturday, 11 August 2012 15:58:00 UTC