[whatwg] DOM Storage feedback
cam at mcc.id.au
Tue Jan 13 16:53:10 PST 2009
> 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.
> > 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
Cameron McCormack ≝ http://mcc.id.au/
More information about the whatwg