Re: Web IDL syntax

Cameron McCormack:
> * Renamed DOMString to string:

Boris Zbarsky:
> I thought there had been at least some mention of this colliding with  
> existing string types in IDLs that are already in use?  I know this will  
> make it much harder for Mozilla to use webidl IDL fragments "as is"...

Yes, but then Jonas replied saying that Mozilla wasn’t intending on
using them as is.  But if you are, …

Ian Hickson:
> I agree; I think this is just going to cause confusion. The specs for 
> years have referred to DOMString throughout.
> Personally if this stays I'll just put a typedef somewhere to define 
> DOMString and not use the native "string" type directly.

All right.  To me, having an intrinsic type called ‘DOMString’ seems
kinda weird.

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

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.

Cameron McCormack ≝

Received on Wednesday, 1 July 2009 02:06:51 UTC