- From: Cameron McCormack <cam@mcc.id.au>
- Date: Wed, 1 Jul 2009 12:05:49 +1000
- To: Boris Zbarsky <bzbarsky@MIT.EDU>, Ian Hickson <ian@hixie.ch>, Maciej Stachowiak <mjs@apple.com>
- Cc: public-webapps@w3.org, Robert Sayre <sayrer@gmail.com>
Cameron McCormack: > * Renamed DOMString to string: > http://dev.w3.org/2006/webapi/WebIDL/#idl-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 Core)? 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 ≝ http://mcc.id.au/
Received on Wednesday, 1 July 2009 02:06:51 UTC