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.
