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

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.

>> We'd likely also have to allow some "readonly" properties to be
>> overwritten using arbitrary values. I.e. evaluating |indexedDB = 42;|
>> or |var indexedDB = 42;| in the global scope would actually change
>> window.indexedDB to the value 42. We end up having to do that right
>> now anyway for a lot of properties since web pages otherwise break due
>> to name collisions with random global variables.
>
> Yes, so set as well as get accessor functions.

Yup.

>> This also has the advantage that it's a change "only" on the WebIDL
>> side. So we'd be free to leave ES with fewer webcompat restrictions
>> when defining how to deal with var/function and properties on the
>> prototype chain.
>
> Cameron may have to take the hit. I had mistakenly thought we could stick to
> ES5.1 and fix SpiderMonkey, but it's just not so.
>
>> 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.

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.

/ Jonas

Received on Saturday, 11 August 2012 08:05:52 UTC