"Boris Zbarsky" <[EMAIL PROTECTED]>
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.
