Re: [whatwg] WebIDL and HTML5

On Tue, Aug 26, 2008 at 9:22 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Garrett Smith wrote:
>>
>> Using ToString, the following result would be obtained:
>
> Yes, I know what you get with ToString.
>
>> After the method createElement(null) is called, there will be no need
>> to tell apart null and "null". I see that. Why is that a problem?
>
> There are other methods where you DO need to tell them apart, of course.
>  All the *NS methods, for example.
>
>> You said that null -> "null" is "lossy". I don't think that's a valid
>> argument. null -> "" is even more "lossy".
>
> Yes, which is why we need a way in IDL to specify exactly what happens to
> null in different cases.  We need a one-to-many mapping here, and just doing
> a single-input-single-output function like ToString doesn't cover all cases.
>
>> null and "" are not equivalent. Setting a style to have the value null
>> should probably convert the value to "null"
>>
>> document.body.style.color = null;
>
> I'd be fine with that (though I'd worry about compat issues), but that
> doesn't address the fact that in some cases null does need to be converted
> to "", or treated just like "".
>
>> That would be a poor design choice
>
> Which?  And on whose part?
>
>> 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.

>> Null is not the same as no value. Null is a type, having one value:-
>> null. The value null is a primitive value in EcmaScript. It is the
>> only member of the Null type.
>
> Yes, yes.  We all know that, and you've repeated it multiple times.  I sort
> of feel like we're talking in circles here.

It is primary point of my argument. However, considering your claim, I
am not certain that everyone here knows that and the discussion seems
to give good indication. I can find further indication in WebIDL[1]:-

| A scoped name that resolves to a boxed valuetype is
| used to refer to a type that corresponds to the set of
| values for the type being boxed, plus the special value null,
| which indicates no value.

Null isn't a special value. The value null is of Type Null. null in
EcmaScript is not the same as null in Java.

>
> One last time, the facts:
>
> 1)  There are DOM methods that accept DOMString arguments or return
>    DOMString values.

Fact.

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

> 3)  The behavior of null is almost always either that of "" or that of
>    "null".  Which one depends on the exact DOM method.

That is false. null has no behavior. Methods have behavior. For
example, EcmaScript's internal ToString has a behavior of converting
null to "null". That is a behavior.

There are (currently) 5 non-string value types: Object (which includes
String object), or any of other 4 primitive types (null, undefined,
number, boolean). How do you want to map all of these? Exception for
number? Exception for Object would be OK, but is somewhat against what
programmers want and expect[2]. What about String Objects? Throwing on
a String object would confuse Java programmers who are dabbling in web
scripting.

1. Specifying null to be interpreted as "" is inconsistent with
EcmaScript's string conversion ToString.
2. Debugging null -> "" is difficult. Programmers that pass null to
objects such as createElement, et c, are using non-standard behavior
that doesn't work consistently across current implementations. Such
programs are buggy.
3. There are many value types that may be passed to DOM methods. The
DOM methods that require domstring should either require a string
value, or should allow conversion to a string value.
4. Creating special cases for mapping/converting non-string values
would introduce complexity.

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.

>
> Therefore, the proposal is to annotate DOM DOMString arguments to DOM
> methods with some indication of whether null should be treated as "" or as
> "null", or as some value not equal to any string.  One of these three
> options can be the default; the other two then require explicit annotation.
>
> Are we on the same page so far?
>

null could be type converted to a string and mapped to a new value.
That's basically option 2 or not option 2.


Garrett

[1] WebIDL http://www.w3.org/TR/DOM-Bindings/#idl-boxed-valuetype
[2] New color-manipulation library, c.l.javascript
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/788d0d6e130d51a4/89c30067413e5a35?lnk=gst&q=toString+color+IE#89c30067413e5a35

> -Boris
>
>

Received on Tuesday, 26 August 2008 17:22:21 UTC