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

Cameron McCormack:
>> I think of it more like that null is the actual namespace URI value, and
>> that an empty string is the non-standard way of specifying it (rather
>> than the other way around).  Which makes me think of this more as
>> something the method should handle, rather than something the bindings
>> worry about.

Boris Zbarsky:
> 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.
The set of values that DOMString can have is the set of all strings plus
the null value.  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”.

> 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.
In Java-land, the String type (as with any reference type) can have null
as a value, and I end up doing special casing like the following in my
DOM implementation code:

  public Element createElementNS(String namespaceURI, String qname) {
      if (namespaceURI != null && namespaceURI.length() == 0) {
          namespaceURI = null;
      }
      …
  }

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

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Saturday, 3 May 2008 03:31:39 UTC