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

On Aug 10, 2012, at 11:14 PM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> On Aug 10, 2012, at 3:25 PM, Brendan Eich wrote:
>>>> 4) The declaration instantiation rules relating to pre-existing bindings
>>>> only consider own properties of the global object.  Inherited properties of the
>>>> global object have no effect upon the processing of function and var
>>>> declarations.
>>> 
>>> This is the incompatible change from ES1-5.1 and reality that I question whether we can get away with.
>> 
>> True, for var declarations.  For function declarations it changed in 5.1 as a result of https://bugzilla.mozilla.org/show_bug.cgi?id=577325 which initially concerned what happens with a global function declaration when there is an inherited access with the same name.  Is the inherited setter called?  We all concluded that it shouldn't. Rule 4 above is essentially an expression of that idea.
> 
> Yes, I remember. 'function' always differed from 'var' in JS: it would create the binding (or throw trying, ES5+).
> 
>> ...
> 
> In primordial JS, writing function onload(){...} defined an onload handler. WYSIWYG and Occam's razor (perhaps too close a shave).
> 
>> In this case, firing the setter is perhaps what the programmer wanted, even if it is a terrible way to accomplish that end.
> 
> It's not that bad if you start from the DOM level 0, especially window.onload being the same binding as function onload() {}.
> 

There seems to be a contradiction between what you describe above for primordial and what ES1-3 said:

For each FunctionDeclaration in the code, in source text order, instantiate a declared function from the FunctionDeclaration and create a property of the variable object whose name is the Identifier in the FunctionDeclaration, whose value is the declared function and whose attributes are determined by the type of code. If the variable object already has a property with this name, replace its value and attributes.

One way to rationalize the two would seems to be by assuming that the global objects has special create property/replace value and attribute behavior (ie, [[DefineOwnProperty]]) that triggers special side-effects for certain properties such as 'onload'.

I still think the cleanest approach is for WebIDL to treat window object properties just like ES  chapter 15 global object properties (probably extended with a standard handling for  global accessor properties).  Then ES can have a consistent semantics for all "built-in" globals. If special behavior is needed for defining certain globals, such as "onload" that can be handled by WebIDL specify custom [[DefineOwnProperty]] behavior for its window object.

Allen