Re: Optional method arguments in the DOM

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.

Received on Friday, 23 June 2006 03:27:36 UTC