Re: Optional method arguments in the DOM

"Anne van Kesteren" <annevk@opera.com>
> What do implementors and authors think of having more optional method 
> arguments in the DOM where that makes sense?

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.

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.

This makes authoring JS library's very easy in my mind,  I don't understand 
Boris's point, you can wrap mozilla's broken xmlhttp.send() by having

function myxmlhttp.prototype.send(chicken) {
  this.xmlhttp.send(String(chicken))
}

(which will of course not pass exactly the same as in other browsers, but it 
will work just as well as using send("Broken UA") does now...)

So the only argument for avoiding it is for UA authors who want to directly 
generate the interface by the IDL, I don't think it's sensible to limit 
ourselves due to a deficiency in something completely unrelated.

cheers,

Jim.

Received on Friday, 16 June 2006 09:08:06 UTC