Re: Optional method arguments in the DOM

"Boris Zbarsky" <bzbarsky@mit.edu>
> Jim Ley wrote:
>> 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.
>
> undefined and null are not at all the same thing, though.

I didn't say they were, I said things that == null, which undefined does.

>> This makes authoring JS library's very easy in my mind
>
> Only if the library never uses ===

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.

> That's off the top of my head in about 3 minutes of thinking; if someone 
> wants to do extensive research on all the ways undefined and null differ 
> across different ECMAScript impls, go for it.  It'd be a prereq for the 
> proposal anyway.

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

>> So the only argument for avoiding it is for UA authors who want to 
>> directly generate the interface by the IDL
>
> Which seems like an eminently sensible thing to do to me.  Dealing with 
> each interface by hand would be a huge undertaking, given how many DOM 
> interfaces there are and how many more are being added all the time.

Not at all, given the large number of optional properties already in browser 
OM, it would make much more sense to use an Interface language that 
supported optionals, it seems very strange to use IDL, when it doesn't meet 
the requirements.  If we didn't have those, then I'd agree there'd be good 
sense to stick with IDL, but given that there are lots of optionals, we can 
carry on using more, because implementors have to use something suitable to 
that task, IDL is not suitable, so I don't particularly see it as 
important - if a UA wants to go IDL+a load of hacks, then I agree it's bad, 
but I can't see that as a likely solution by UA authors, it seems rather 
fragile.

I agree it could be relevant for UAs wanting to implement the specification 
who do not want to implement a Browser Object Model, but I think that's a 
minority use case, especially for WEBAPI's deliverables.

> [1] Try this: I get interoperable results in Opera, Konqueror, and Gecko 
> that indicate that window[undefined] behaves weirdly:
>
> var x = window;
> x[null] = 1;
> x[undefined] = 2;
> alert(x[null]);
> alert(x[undefined]);
>
> here setting x to new Object() instead of window actually gives different 
> behavior from having it be window (but interoperably different!) in all 
> three browsers.

Of course!  That's completely to specification, the square bracket notation 
calls toString - so your x[undefined]=2 line is equivalent to 
window.undefined, but window.undefined is of course read only.  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.

Cheers,

Jim.

Received on Friday, 23 June 2006 09:37:29 UTC