<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 10, 2012, at 11:14 PM, Brendan Eich wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Allen Wirfs-Brock wrote:<br><blockquote type="cite">On Aug 10, 2012, at 3:25 PM, Brendan Eich wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">4) The declaration instantiation rules relating to pre-existing bindings<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">only consider own properties of the global object.  Inherited properties of the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">global object have no effect upon the processing of function and var<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">declarations.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">This is the incompatible change from ES1-5.1 and reality that I question whether we can get away with.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">True, for var declarations.  For function declarations it changed in 5.1 as a result of <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=577325">https://bugzilla.mozilla.org/show_bug.cgi?id=577325</a> 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.<br></blockquote><br>Yes, I remember. 'function' always differed from 'var' in JS: it would create the binding (or throw trying, ES5+).<br><br><blockquote type="cite">...</blockquote><br>In primordial JS, writing function onload(){...} defined an onload handler. WYSIWYG and Occam's razor (perhaps too close a shave).<br><br><blockquote type="cite">In this case, firing the setter is perhaps what the programmer wanted, even if it is a terrible way to accomplish that end.<br></blockquote><br>It's not that bad if you start from the DOM level 0, especially window.onload being the same binding as function onload() {}.<br><font class="Apple-style-span" color="#006312"><br></font></div></blockquote><br></div><div>There seems to be a contradiction between what you describe above for primordial and what ES1-3 said:</div><div><br></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>For each <i>FunctionDeclaration</i> in the code, in source text order, instantiate a declared function from the <i>FunctionDeclaration</i> and create a property of the variable object whose name is the <i>Identifier</i> in the <i>FunctionDeclaration</i>, 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.</div></blockquote><br><div>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'.</div><div><br></div><div>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.</div><div><br></div><div>Allen</div><div><br></div><div><br></div></body></html>