On Wed, Aug 27, 2008 at 2:39 PM, Boris Zbarsky <[EMAIL PROTECTED]> wrote: > Garrett Smith wrote: >> >> Given that, I suggest moving forward: >> Test, then document those methods as having special behavior. Do >> this not by a null->value mapping, but by documenting the method's >> algorithm in simple terms. e.g. "if X is not a string, throw an error" > > But giving a (per-method) mapping means that the algorithm can then be > machine-generated from the IDL, which is an interoperability win: less > chance of a mistake being made. > > So why are you opposed to having such per-method mappings, as needed? >
I can appreciate the desire to make the task of implementing the spec in an automated fashion. That is a desire, however, not a need. What I opposed is calling null a string. Null is not a string by the definition in the DOM 3 spec[1]. A String variable, in Java, can have the value null, but this can be determined: if(s == null). However, WebIDL does lump null into domstring. What WebIDL does creates compatibility issues in an attempt to standardize bugs. Moving forward, if null is allowed, it should not be called a string. However, if only a DOMString is allowed, and null is passed, it should not require a one-off mapping. Garrett [1] DOM3 domstring http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-C74D1578 [2] WebIDL domstring http://dev.w3.org/2006/webapi/WebIDL/#idl-DOMString > -Boris >
