Re: Optional method arguments in the DOM

Jim Ley wrote:
> You're argument that a library would be difficult to write, it's easy 
> for a library not to use ===, so that's a rather strange argument.

My point was that there are suddenly all sorts of gotchas involved in writing a 
library if you allow this sort of thing.

> It's part of the specification of ES, and there are no problems with it 
> in any implementations - a million scripts would break:

I didn't say there are problems; I said the behavior is not as simple as you 
make it sound.

> Not at all, given the large number of optional properties already in 
> browser OM

I'll assume you meant "optional arguments".  In which case there really aren't 
all that many.  It might be worth it to make a list of the existing ones to see 
what things look like.

> it would make much more sense to use an Interface language 
> that supported optionals

I'd be much happier with that than with using IDL but then hand-writing 
exceptions in the ECMAScript bindings, which is what the original proposal 
sounded like to me.

Perhaps I should clarify what my initial concern was with the example of how 
Mozilla actually works.  At the moment, when you make a call from JS on a DOM 
object, there is a layer that translates the JS function invokation into a C++ 
function call.  This layer has to know how to translate the arguments to the JS 
function (which are typically JS Objects, JS Strings, etc) into C++ objects, 
wchar_t pointers and so forth.  Since C++ is strongly typed, the translation 
needs to figure out which exact type to convert to; this is where the IDL is 
actually used.  The translation layer looks up the IDL declaration for the 
function being called, and that tells it whether to convert a JS Object to Node 
or Element or whatever.

Like I said, automating this part makes incredible amounts of sense -- otherwise 
you'd have to hand-write the argument conversion for every single function in 
the DOM.  We do do manual argument conversion for a small number of functions 
that have optional arguments in DOM level 0, and it's quite a pain to do that way.

Now there are several obvious modifications to this system that could be made:

1)  It could be assumed that any time the number of arguments
     actually passed to the function is smaller than the number
     declared in IDL, the remaining ones should be assumed to be
     undefined and attempts be made to convert them to something
     reasonable.  This would mean that _all_ DOM methods would
     sprout optional arguments.  I'm OK with this.
2)  Functions in IDL could be somehow tagged with the number of
     arguments at the end that are optional.  If a different interface
     language needs to be used here, so be it.  I'm OK with this too.
3)  We could leave the IDL exactly as-is and write non-computer-parseable
     prose to indicate where optional args are OK and where they're not OK.
     This was the original proposal.  I'm NOT OK with this, for the reasons
     I've already stated.

Note that solutions #1 and #2 do not address a lot of common argument-defaulting 
scenarios (e.g. document.open type stuff) in DOM0 because those involve 
defaulting to a value that's not == to undefined.

> but window.undefined is of course read only.

Why?

> This isn't particularly relevant to the javascript library author, as a hash 
> on window is not something you can do in a library for hopefully obvious 
> reasons.

Why not?  Just createElement an iframe that loads some of your stuff (e.g. this 
is the only sane way to convert an HTML document into a DOM in browsers), and 
then use the window in it.  There's more than one Window object around.  ;)

-Boris

Received on Friday, 23 June 2006 14:51:08 UTC