Re: Optional method arguments in the DOM

> 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.

This I very much like, if it's easy to implement, it makes them essentially 
equivalent to what ES users expect, which is what I want!

> 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.

I'm happy with that, it's the extra==undefined I want to be consistent with 
non-host functions in ES.

>> but window.undefined is of course read only.
>
> Why?

oops, sorry, ES3 - 15.1.1.3 actually only has DontDelete and DontEnum for 
undefined, so it shouldn't be ReadOnly, the readonly appears to be an 
"extension" to ES3.

>
>> 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.  ;)

Okay, so you're right you "could" do it in a library, but you'd be going 
pretty mad - the above method is still unsafe unless the document you load 
into the iframe contains no script.

Cheers,

Jim.

Received on Friday, 23 June 2006 15:00:19 UTC