Re: [whatwg] WebIDL and HTML5

On Wed, Aug 27, 2008 at 4:39 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> Garrett Smith wrote:
>>>
>>> So is everything else.  This particular desire has great benefits,
>>> however,
>>> so it needs to have great drawbacks as well to not be done, right?
>>


>
> That's an issue even if it's just the spec text that says that null is
> treated in a special way.
>

There was a proposal to treat null in a language-dependent manner.
Developers of EcmaScript could reasonably expect null maps to "null".

> Again, what is your specific problem with the specific approach of
> annotating null/undefined conversions as opposed to just describing them in
> the spec text?
>
>> I disagree. That the DOM spec does not include null. It is very
>> verbose on what it does include, so it's not by accident.
>
> Then how do you account for all the places in the same spec that talk about
> passing null to DOMString arguments?
>
>> I believe that null should be handled based on what it is.
>
> That's fine.  How is it compatible with the existing specs?
>

It is not compatible? Where? How? A spec mentioning null for a method
that accepts a string does not make null a string. It means they
mentioned null, probably to appease Java programmers' concern for when
to throw npe or raise analagous DOMException.

>>> Yes, because de-facto DOM does this already.

what is "de-facto" DOM? You mean browsers? Browsers are totally
inconsistent with each other with null.

>>>
>>
>> My examples clearly show otherwise. null is handled differently in
>> Firefox, [Opera/IE], Safari, depending on what DOM method /property it
>> is used for.
>
> I don't see what that has to do with my statement above, that de-facto DOM
> method specifications assume that null can be passed for a DOMString and
> that a number of DOM methods specify what should be done in that case.
>

That the specs talk about what happens in the event that a null slips
doesn't change what a string is.

The spec discussing null does not change what null is or what a string is.

Why do the specs mention that? Who knows.

They might mention this case because this can happen in Java and they
wanted to address that. The spec mentions that domstring maps to Java
string, so they did consider Java. A String variable can have the null
value in Java. The fact that the Java compiler lets this happen does
not mean that the variables value is a string. It's still null.

> Honestly, you can stop copy/pasting the same examples in.  We've seen them.
>

That was a new example I posted.

>> That is true. There are methods that discuss what happens when you
>> pass null to a method that accepts a domstring.
>
> Right.  That discussion is what should be moved into IDL annotations.

Each method should not be moved to IDL.

I can understand that you want to think of null as a String. I'm going
to give this a rest because it's wearing me out. Null is not a string.
I am capable of using string value where domstring is required.

Garrett

>
> -Boris
>
>

Received on Thursday, 28 August 2008 00:08:43 UTC