Re: [whatwg] WebIDL and HTML5

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