Jonas Sicking: > So it behaves different from passing in an empty string? For some > functions this surprises me, such as for the namespace parameter for > getAttributeNS, I would think that we there treat "" the same as null.
Not necessarily, but I agree that would be a better thing to report. I’ll rejig the tests to get that information. Cameron McCormack: > > OK. So what is more important for choosing the default: fewer > > exceptions (and thus fewer [Null=…] things polluting the IDL), > > consistency with the default stringification behaviour of ECMAScript, > > or avoiding the somewhat counterintuitive default behaviour of > > converting a valid value of the type to a different value of that type? > "converting a valid value of the type to a different value of that > type", which values exactly? null. It feels slightly strange to me to treat null as a “second class value” by default. But I’ll get over it. :-) It may actually be indicative of a need for two distinct types: strings (i.e., possibly empty sequences of characters) and strings-or-null. But I don’t know if it’s worth rewriting everything in this way. > I think another factor, that you haven't mentioned, that is very > important is web compatibility. But beyond that I think I would rate > fewer exceptions highest. Well, I assume that writers of specs that document already-implemented interfaces will choose the appropriate [Null] annotation (or lack of it) for web compatibility. Which to choose as the default is orthogonal, I think. -- Cameron McCormack ≝ http://mcc.id.au/