(putting this back on list)
On Tue, Aug 26, 2008 at 12:38 PM, Andrew Oakley
<[EMAIL PROTECTED]> wrote:
> 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.
>
I agree that the general programmer expectation that type conversion
to a domstring would occur. This would be an issue with dynamically
typed languages. In a few examples:
// 1. ToString( number )
// Existing code uses this. It seems to work in all browsers.
el.style.zIndex = 0;
// 2. ToString( object )
// Fails in IE.
var colorObject = {
r : 16, g: 255, b: 16,
toString : function() {
return "rgb(" + this.r + "," + this.g + "," + this.b+")"; }
}
document.body.style.backgroundColor = colorObject;
// ToString( boolean )
// assume the attribute is set with "false"
inp.setAttribute('disabled', false);
inp.getAttribute('disabled') === "false"; // true.
inp.disabled === true; // also true (false in IE, IIRC).
> >> 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.
>
Given the following code (which we agree is not standard):-
document.body.textContent = null;
- what is the natural expectation?
a) raise exception
b) textContent is set to "null"
c) textContent is set to ""
>> 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).
>
In Java, a String is an object and null can be passed to any method
that accepts a String. A misfortunate Java program that called
createElement(null) would either have to:
a. throw a NullPointerException (or raise analagous domexception)
b. do a conversion of the input to a String
If the language were EcmaScript, the program would not have compile
errors, so it would be necessary to handle at runtime:-
var el = document.createElement();
var el = document.createElement(undefined);
If the argument is null/undefined, an exception is raised,
Otherwise, an element of the specified tagName is created.
(applies to all languages)
Does this sound reasonable?
The difference is that null is not lumped into all possible string
values. null is null. Checking null can be done in any language.
Consideration:
Some methods that accept a string value may raise exceptions on
null/undefined (createElement)
Some methods may have special handling of null/undefined (window.open,
insertBefore).
For all methods, implementations of dynamically typed languages
(EcmaScript), must either:
A) handle number, object, boolean, in such a way that that string
conversion of that language would take effect (in EcmaScript,
ToString)
B) raise a DOMException.
Examples of non-string value used for domstring: textContent = null,
style.color = obj, style.height = 0, el.setAttribute('disabled",
true), document.title= new String("hello");
Does this sound reasonable?
Garrett
