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:39:04 +1000
To: "Web APIs WG (public)" <public-webapi@w3.org>
Message-ID: <20080503033904.GK5335@arc.mcc.id.au>

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

Maciej Stachowiak:
> Well, JS is an odd duck here. It does not have an instance of the string 
> type, but it does have a null value (of a different type) and dynamic 
> type conversion and a weird rule for how null is converted to string.
> I guess what NoNull is saying is that null should stringify according to 
> JS rules, yielding "null", with the default assumption being that  
> DOMString parameters in IDL may take JS null.


> But NoNull does not seem like a very clear way to express that idea
> (at least to me, as an implementor more familiar with JS and DOM
> internals than with the details of OMG IDL).

It is sort of an indirect way of saying that, yes.

> Also, notwithstanding the polite fiction that DOMString is a  
> valuetype<sequence<unsigned short>>, in real bindings it is treated as a 
> custom type that matches the native language's string type. So I would 
> not read too much into its theoretical IDL definition.

Understood and agreed.  In W3C DOM specs, valuetype<> seems to be used
only for defining DOMString.  In the end, it’s probably more useful to
give Web IDL a proper string type that doesn’t include the null value,
and have the extended attributes describe what happens when you give it
a null (the default being that it is treated as if '' was passed, if
that is in fact the more common case).

Cameron McCormack ≝ http://mcc.id.au/
Received on Saturday, 3 May 2008 03:39:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:26 UTC