[whatwg] DOM Storage feedback

[Jonas Sicking]

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