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

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.

Yes.

> 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