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
