Re: [selectors-api] Extended Attribute [NoNull] in the IDL

Cameron McCormack wrote:
>> But the method signature in IDL is DOMString.  So by the time it sees the 
>> argument, it will be a DOMString.  The only question is which DOMString.
> 
> Because DOMString is defined as:
> 
>   typedef DOMString valuetype<unsigned short>;
> 
> then the null value should be one of the values that that type can have.

As Maciej said, this is a polite fiction.  In practice, the value is converted 
to whatever represents strings in the underlying language.  As you noted, in 
Java it becomes a String reference.  In Gecko and Webkit it becomes a String 
object (not a String object pointer, which would be closer to the Java behavior).

> The set of values that DOMString can have is the set of all strings plus
> the null value.

Agreed.

> At least, this is what it means in OMG IDL.  Hence why
> I’ve made [NoNull] mean “oh even though this is a boxed valuetype, I
> don’t really want to handle the null value, so turn it into something
> else”.

I see.

>> In Gecko, if you pass in "" it will see the string "".
>>
>> If you pass in null, it will see a string that is equal to "" but has a 
>> "this is a null string" bit set.
> 
> Sounds similar to what Maciej was saying about null strings in WebKit.

Yep.

>> Conceptually, the latter is more like a |char * str = NULL| and the 
>> former is more like a |char * str = "";| but both represented by a String 
>> object of some sort.
>>
>> It might make sense to declare this the default conversion of null to 
>> DOMString and then have NoNull mean that the Object.prototype.toString 
>> conversion should be used instead.
> 
> What about when the null value is really wanted?

In both Gecko and Webkit you can tell apart a string that was a explicitly "" 
and a string that was null and got converted to "" plus the null bit.  You just 
have to do an extra check.  So any time null and "" are defined to behave the 
same way, you don't need the sort of extra code that your Java example is forced 
to use.  But if they are defined to have different behavior (which is the rare 
case in DOM-land), then you can check which one you really have and switch 
accordingly.

Note that you could get the same setup going on in Java if you used a wrapper 
class around String and converted JS null into a non-null reference to a 
wrapper.  Or we could get the Java behavior in Gecko if we used wchar* for 
strings...

I guess it might be nice if the IDL indicated which one of three cases:

1)  null means the same as "" in this case
2)  null means the same as "null" in this case
3)  null means something different from either of those two cases in this case

holds.

Then the binding layer could, for Webkit and Gecko, map cases 1 and 3 to these 
special string objects with the null bit set, and case 3 could be handled by 
hand-written code.  Case 2 would map null to the string object holding "null". 
Or something.

The Java binding layer could make null to a String holding "" in case 1, to a 
String holding "null" in case 2, and to a null String reference in case 3.  The 
you could remove your checks for an empty string in createElementNS(), etc if 
you wanted.  Again, or something.

-Boris

Received on Saturday, 3 May 2008 03:46:25 UTC