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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
