- From: Cameron McCormack <cam@mcc.id.au>
- Date: Wed, 14 Jan 2009 11:53:10 +1100
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/
Received on Tuesday, 13 January 2009 16:53:10 UTC