- From: Cameron McCormack <cam@mcc.id.au>
- Date: Sat, 3 May 2008 13:39:04 +1000
- To: "Web APIs WG (public)" <public-webapi@w3.org>
Cameron McCormack: >> I think because DOMString is actually a >> valuetype<sequence<unsigned short>, a null value is allowed. Maciej Stachowiak: > Well, JS is an odd duck here. It does not have an instance of the string > type, but it does have a null value (of a different type) and dynamic > type conversion and a weird rule for how null is converted to string. > > I guess what NoNull is saying is that null should stringify according to > JS rules, yielding "null", with the default assumption being that > DOMString parameters in IDL may take JS null. Yes. > But NoNull does not seem like a very clear way to express that idea > (at least to me, as an implementor more familiar with JS and DOM > internals than with the details of OMG IDL). It is sort of an indirect way of saying that, yes. > Also, notwithstanding the polite fiction that DOMString is a > valuetype<sequence<unsigned short>>, in real bindings it is treated as a > custom type that matches the native language's string type. So I would > not read too much into its theoretical IDL definition. Understood and agreed. In W3C DOM specs, valuetype<> seems to be used only for defining DOMString. In the end, it’s probably more useful to give Web IDL a proper string type that doesn’t include the null value, and have the extended attributes describe what happens when you give it a null (the default being that it is treated as if '' was passed, if that is in fact the more common case). -- Cameron McCormack ≝ http://mcc.id.au/
Received on Saturday, 3 May 2008 03:39:42 UTC