Re: Handling too few arguments in method calls

Aaron Boodman:
> But there is also an issue of legacy code. I brought this issue up in
> a webkit bug awhile ago, and one concern from the webkit developers
> was that introducing an exception would almost certainly "break"
> sites. My opinion is that those sites are almost certainly already
> broken.

I would worry about that, too.  The amount of brokenness it experiences
because of a change to using exceptions could be far greater than it is
currently.

> As a simple example, consider the setAttribute() method. Both
> arguments are required, but in WebKit, if you don't pass either value
> it is coerced to string. So if we take a simple attribute like
> "title":
> 
> someElement.setAttribute("title");  // throws in Firefox, sets title
> to "undefined' in WebKit
> 
> Philosophically, I want to say that pages that are passing too few
> arguments to DOM APIs are already broken, just in less obvious ways.
> Breaking in more obvious ways would be better.

So we could change this to be:

  interface Element {
    void setAttribute(in DOMString name, [Optional] in DOMString value);
    …
  };

to keep setAttribute("title") working, but I think making the
optionalness of the argument to other language bindings in this case
isn’t a good idea.  Also in this particular case it doesn’t seem like it
would be needed for web compatibility, if Firefox and Opera can get away
with throwing here.

If there’s a real need to allow some arguments on particular operations
in ECMAScript to be optional, and coerced from an undefined value, then
we can introduce an ECMAScript-specific extended attribute that permits
this.  But in general I agree that it would be better if we could remain
strict.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Friday, 26 June 2009 01:07:47 UTC