Re: Web IDL syntax

On Jun 30, 2009, at 7:05 PM, Cameron McCormack wrote:

> Maciej Stachowiak:
>> WebKit doesn't have the same technical constraints as Mozilla,  
>> however
>> this change doesn't really seem helpful and it would be annoying to  
>> have
>> to replace all instances of DOMString in our existing IDL.
> find . -name \*.idl | xargs perl -i -pe s/\<DOMString\>/string/g
> But OK.  By the way, do you use DOMString as an intrinsic type, or do
> you use a sequence<unsigned long> boxed valuetype (as defined in DOM
> Core)?

We treat it as an intrinsic type.

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

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

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


Received on Wednesday, 1 July 2009 04:07:10 UTC