- From: Andrew Oakley <andrew@ado.is-a-geek.net>
- Date: Tue, 26 Aug 2008 20:47:05 +0100
- To: public-webapps@w3.org
Garrett Smith wrote: >>> document.createTextNode(0) >>> >>> Should this create a textNode "0" or ""? >> Or throw a typeError? >> > > A TypeError might seem technically correct for a native method, > however, most dom methods "raise a dom exception." > > An implementation that created a text node with value "0" would be non-standard. The WebIDL specification really should specify what type conversions may or may not happen. I think it is reasonable to expect a method that wants a string argument to cause a language conversion if that is the style of the calling language. In the case of ECMAScript we expect to be able to type convert when passing to functions because thats how the standard library objects work. If we really did have some numeric calculation and wanted to display it in a text node calling createTextNode with a number and expecting a type conversion is reasonable. Manual type conversion in ECMAScript is really horrible. >> 2) In general, such methods need to be able to tell apart null and all >> string values (including "" and "null"). > > They need to determine value type so that they can either throw or > handle. null, 0, undefined, new String('x'), are all not strings. Normally they don't though. Normally we just want a string. Sometimes we want either a string or null. I'm not aware of any APIs with any more complex requirements. > Methods that accept a domstring could: > 1) raise exception for null/undefined > 2) convert the argument that is not a string to a string, > 3) raise exception if the argument is not a string > 4) 1 and 2. > > Consideration: > Option (1): Would make bugs more apparent. > Option (2): Could be made to be consistent with EcmaScript ToString, > for consistency. > Option (3): Would make bugs more apparent, but would go against > programmer expectation[2] > Option (4): Would make some bugs more apparent, but would also allow > programmers to pass an object where a string was required. > > The options that you seem to favor is (2), and I don't have a problem > with that. What I do have a problem with is making up a new string > conversion mapping and calling null a string with no value. That's > just wrong. The downside to making up a new string conversion mapping > is that it introduces complexity, doesn't account for other primitives > or objects, and conflicts with a perfectly good existing standard, > EcmaScript's ToString. I would argue that methods which need to do anything other than have null converted to "null" should state that they allow Null as well as DOMString types. The method itself can be responsible for the non-standard conversion. And then I think we need a table to score type conversions for the ambiguous cases - if a method accepts DOMString and Null types, and is passed the undefined value, should we use "undefined" or null? Exceptions should be thrown if we cannot do a conversion for whatever reason. I also think that we should not make the string conversion "consistent" with the ECMAScript ToString, I think we should use the calling languages type conversion routines (for any weakly typed language).
Received on Tuesday, 26 August 2008 19:47:42 UTC