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).
