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

On Aug 11, 2012, at 6:46 PM, Cameron McCormack wrote:

> Brendan Eich:
>> As bz and others point out, the object detection w/ var pattern can
>> arise for operations, e.g. for requestAnimationFrame, using the same
>> 
>>   var requestAnimationFrame = window.mozRequestAnimationFrame || ... ||
>> window.requestAnimationFrame;
>> 
>> pattern. So WebIDL operations (JS methods) on the global would be
>> promoted to "own" too. They'd be configurable, if I recall correctly,
>> and either writable or replaceable. Do I have that right?
> 
> OK.  So one thing that I think has been pointed out is that moving properties for operations on to window makes it harder to monkeypatch addEventListener and friends.  We *could*, if we thought it was important, have the properties on window forward on to the ones from the prototype.
> 
> Some other questions on specifics:
> 
> 1. If we don't do that auto-forwarding, does Window.prototype still need to exist?  What should window.__proto__ be?

Requirements on the global object are specified here: http://ecma-international.org/ecma-262/5.1/#sec-15.1 It says that the value [[Prototype]] is implementation defined, but in practice in needs to inherit from Object.prototype.  So, Object.prototype seems like a strong candidate for being the actual [[Prototype]] value.


> 
> 2. If Window.prototype still does exist, should it be empty?

I don't seen, right off, why it  needs to to exist as anything other than Object.prototype.


> 
> 3. The only writable IDL attributes on Window are:
> 
>     attribute DOMString name;
>     attribute DOMString status;
>     attribute WindowProxy? opener;
> 
> and all of the event handler attributes like "onclick".  How do these need to behave if script blithely tries to use variables of the same name?  With this:
> 
>  <script>
>    alert([window.status, typeof window.status]);
>    window.status = "hello";
>    alert([window.status, typeof window.status]);
>  </script>
>  <script>
>    var status;
>    alert([window.status, typeof window.status]);
>    status = 1;
>    alert([window.status, typeof window.status]);
>  </script>
> 
> Gecko and Opera alert:
> 
>  ,string
>  hello,string
>  ,undefined
>  1,number
> 
> while Chrome and Safari alert:
> 
>  ,string
>  hello,string
>  hello,string
>  1,string
> 
> which seems to indicate that they're setting the IDL attribute.  I guess this is related to whether we want "function onclick(){}" to invoke the setter.

global var declarations don't over-write or redefine own properties of the global object. What a JS programmer would expect for any built-in would be:

 ,string
 hello,string
 hello,string
 1,number

I don't really see what would be wrong with not doing the automatic string conversion on assignment, but if you really want to do it we can var declarations handle pre-existing own accessor properties in the same way that own data properties are handled.

> 
> With this:
> 
>  <body onerror="alert('exception')">
>  <script>
>    alert([String(window.onclick), typeof window.onclick)]);
>  </script>
>  <script>
>    var onclick = 1;
>    alert([String(window.onclick), typeof window.onclick]);
>  </script>
> 
> Gecko, Opera and Chrome alert:
> 
>  null,object
>  1,number
> 
> which could mean shadowing or treating "onclick" as IDL type "any" and treating non-Function values as null, while Safari alerts:
> 
>  null,object
>  null,object
> 
> which looks like it's invoking the setter but ignoring the assignment of a non-Function value.

see, the subthread that Brendan and I here having about: function onload () {} declarations.

Do onload and friends need to even exist as global object properties if they haven't been explicitly set?  Why can't the triggering mechanism for them simply look to see if they have been created?  Why can't they be simple data properties of the global object?  Basically, what would a JS programmer do if they were implemented the same mechanism?

Allen

Received on Sunday, 12 August 2012 02:17:58 UTC