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

On May 2, 2008, at 8:03 PM, Cameron McCormack wrote:

>
> 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?

It's not generally a meaningful distinction. Our string type  
internally distinguishes empty and null strings. JS strings do not  
have such a distinction, and null is not a valid instance of the  
string type. Both typically act the same as the empty string, but a  
very few places may check specifically for null string basically as a  
hack to let JS null pass through a string-typed argument.

>> 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.

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).

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.

>> 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│?

For our bindings code at least we prefer to be specific, since |any|  
without additional knowledge of the actual types possible would  
require hand-coding.

Regards,
Maciej

Received on Saturday, 3 May 2008 03:28:46 UTC