- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 30 Jun 2009 21:06:29 -0700
- To: Cameron McCormack <cam@mcc.id.au>
- Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, Ian Hickson <ian@hixie.ch>, public-webapps@w3.org, Robert Sayre <sayrer@gmail.com>
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). Regards, Maciej
Received on Wednesday, 1 July 2009 04:07:10 UTC