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

Allen Wirfs-Brock wrote:
> On Aug 11, 2012, at 6:46 PM, Cameron McCormack wrote:
>> 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.

That was true in the original DOM in Netscape 2. There was no Window 
pseudo-constructor or Window.prototype. All the 
masquerading-as-data-property accessors, e.g. window.status, were "own" 
properties.

This changed with WebIDL but also IIRC with earlier evolution. I'll let 
someone else do the hg and cvs archeology to show Gecko's history.

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

Back to the future! ;-)

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

(Again, function is different from var and this example uses var, so 
let's defer function for now.)

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

I think we must. ES5 and 5.1 do, IINM, but the "must" comes from 
implementations doing so, as shown by Cameron's 1,string. The 
window.status setter is undisturbed by 'var', and it normalized RHS type 
to string.

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

Again, 'function' != 'var'. Cameron's example again uses only 'var'. 
Happy to talk 'function' too, separately sub-thread.

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

As noted, they started out that way 17 years ago. I think WebIDL and 
interface-based method definition made onload, e.g., predefined on 
window objects, or more recently on Window.prototype. Was this useful? 
Was it intended specifically (for window, not just intended generally 
due to WebIDL's uniform rules for binding its definitions in JS)?

/be

Received on Sunday, 12 August 2012 02:57:46 UTC