Jim Ley wrote:
In ECMAScript DOM's definately, anything that accepts null should
definately work if a user doesn't explicitly define null, because ES
authors expect functions to behave that way, with all non-passed
functions simply set to undefined.
undefined and null are not at all the same thing, though.
Script authors should expect consistency here between host objects and
native ES objects, so optional methods are expected, even if the only
defaults are undefined and things that == undefined.
So what should undefined become? Null? False? True? Some random "default"
DOM node in some cases?
This makes authoring JS library's very easy in my mind
Only if the library never uses === and if all defaulting is done in ways that
only default things to something == to undefined, and as long as the object
passed in is not used as a key to store stuff on other objects [1]. That's off
the top of my head in about 3 minutes of thinking; if someone wants to do
extensive research on all the ways undefined and null differ across different
ECMAScript impls, go for it. It'd be a prereq for the proposal anyway.
So the only argument for avoiding it is for UA authors who want to
directly generate the interface by the IDL
Which seems like an eminently sensible thing to do to me. Dealing with each
interface by hand would be a huge undertaking, given how many DOM interfaces
there are and how many more are being added all the time.
I don't think it's sensible
to limit ourselves due to a deficiency in something completely unrelated.
Sure, if you don't care whether UAs implement your spec. ;)
-Boris
[1] Try this: I get interoperable results in Opera, Konqueror, and Gecko that
indicate that window[undefined] behaves weirdly:
var x = window;
x[null] = 1;
x[undefined] = 2;
alert(x[null]);
alert(x[undefined]);
here setting x to new Object() instead of window actually gives different
behavior from having it be window (but interoperably different!) in all three
browsers.
