W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

Re: [selectors-api] Extended Attribute [NoNull] in the IDL

From: Cameron McCormack <cam@mcc.id.au>
Date: Sat, 3 May 2008 13:03:08 +1000
To: "Web APIs WG (public)" <public-webapi@w3.org>
Message-ID: <20080503030308.GF5335@arc.mcc.id.au>

Maciej Stachowiak:
> I'm not sure what NoNull is supposed to mean, but existing DOM APIs that 
> take strings almost always either treat JS null the same as "", or the 
> same as "null". I think Web IDL should define a property to distinguish 
> these cases. In WebKit's IDL we have the overly verbose  
> [ConvertNullToNullString] extended attribute for the first case (we  
> internally distinguish null string from empty string and I think there  
> may be a tiny number of APIs that actually treat null and empty  
> differently). I am not sure which of these behaviors [NoNull] applies  
> to.

[NoNull] is meant to mean that null values won’t get passed through, and
instead have to be treated the same as a value of whatever is inside the
valuetype<>.  Thus for DOMString, you’d get the normal stringification
behaviour.

What’s the distinction between a null string and the null value?  Is the
null string just a way to force the null value into your string type,
internally?

> We have similar extended attributes for IDL method return values or  
> attributes that are nominally DOMString but may return other values such 
> as null, or occasionally undefined,

I think because DOMString is actually a
valuetype<sequence<unsigned short>, a null value is allowed.

> or in at least one crazy case, boolean false (thanks to whoever
> designed queryCommandValue).

Maybe in crazy cases like that the return value should be │any│?

-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Saturday, 3 May 2008 03:03:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 3 May 2008 03:03:49 GMT