Re: Web IDL syntax

Cameron McCormack:
>> I can easily rename the type back to DOMString . I’d like to know if
>> you all think there is any problem in keeping the name as DOMString
>> but removing the null from its set of values, and requiring the use
>> of the nullable type ‘DOMString?’ to specify a string type that
>> does allow null.  Because then it is different from the traditional
>> DOMString as defined in DOM Core.

Maciej Stachowiak:
> I haven't investigated this deeply. I'm not sure it is meaningful in  
> ECMAScript to say that null is "not allowed" in some particular case -  
> rather, it is necessary to specify what happens when null is passed.  

I agree that we need to specify what happens when null is passed, just
as we need to specify what happens when any kind of ECMAScript value is
passed.  That doesn’t make it not useful to specify in the IDL what
values are expected.

To me, it seems like some operations have useful behaviour defined for
strings and some for strings plus the value null.  If the null value is
not useful across all language bindings, then I think that should be
part of the actual argument type, rather than an annotation.

> There's extended attributes to specify that it should be treated as "", 
> undefined, or null, so it seems odd to have a different type to say it 
> should be treated as the string "null". I'm not sure if I correctly 
> interpreted what you meant by "allow null".

It wouldn’t be that you have a different type just to mean “treat it as
the string "null"”.  It would be that this type (‘DOMString’, as opposed
to ‘DOMString?’) has behaviour which is not to just pass the null value
through untouched.

By “allow null” I mean whether the operation/attribute on the IDL level
is expecting null as a valid value.

So, with the changes I’ve made, the valid values of the DOMString type
are all possible strings (i.e., sequences of 16 bit code units), and the
valid values of the DOMString? type are all possible strings PLUS the
null the value.

Operations and attributes of type ‘DOMString?’ would always pass a null
value through unconverted (well, except for the conceptual conversion
from the ECMAScript null value to the IDL null value).

Operations and arguments of type ‘DOMString’ would always convert a null
value into some kind of string value.  The default for this is still to
convert it to the string "null", which can be changed to "" by using
[TreatNullAs=EmptyString].  But I’m open to switching this around, I
just still haven’t got around to testing exhaustively to see which would
is more common.

Does this make sense?

> Also, as I understand it, there's no way in the Java type system to  
> exclude null from the range of a reference type, so there too it's  
> necessary to say what happens with a null string (exception, same as  
> empty, special behavior different from any string).

Right, just as there’s no way to do it in ECMAScript because there is no
strong typing.  Currently the spec says to throw a NullPointerException
if null is passed to something of type DOMString in Java.  For
‘DOMString?’, it is passed through unchanged.

If special behaviour different from any string is needed, then the
operation/attribute really should have been defined to take a
‘DOMString?’, i.e. a type that includes the null value.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 2 July 2009 06:05:26 UTC