- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 10 Feb 2009 19:04:22 -0800
On Tue, Jan 13, 2009 at 4:53 PM, Cameron McCormack <cam at mcc.id.au> wrote: > 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. :-) The point would be to not do it by default. I.e. default behavior is to treat null as a valid value that is left untouched by default. And only convert it to n-u-l-l when specified in IDL. To answer your original question. I think the most important thing is to have few exceptions that authors have to learn. > 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. Yeah / Jonas
Received on Tuesday, 10 February 2009 19:04:22 UTC