Re: [Erratum] core-14. DOMImplementation.hasFeature (Re: hasFeature with "unspecified" version)

>Maybe this should better read
>  "If the version is null (or undefined) or empty string..."
>because in ECMAScript the most common way to not supplying an argument is
>leaving that argument "undefined"

A few thoughts:

I'd say that's a binding issue -- "what does null mean in this binding" --
since the main spec is supposed to be language independent and many
languages do not permit optional/implied arguments or method overloading.

There's a consistancy question. If we declare that undefined shall be taken
as null here, we should probably do so throughout the API.

Purely personal reaction: it strikes me as a bit late to be making that
sort of large-scale change in  the bindings. I admit it's likely to be
backward-compatable, because nobody should have been issuing the truncated
form of these calls... but forcing every implementation to update itself in
order to support what is, at most, a minor coding convenience seems hard to
justify. So I'd tend to put this one in the category of "Might have been
nice if we'd thought of it, but we missed our opportunity."

Of course I'm not an ECMAScript developer, so my opinion isn't highly
significant and I'm perfectly willing to be outvoted on this one.

Joe Kesselman  / IBM Research

Received on Thursday, 12 July 2001 08:48:53 UTC