On May 2, 2008, at 8:03 PM, Cameron McCormack wrote:
Maciej Stachowiak:
I'm not sure what NoNull is supposed to mean, but existing DOM APIs
that
take strings almost always either treat JS null the same as "", or
the
same as "null". I think Web IDL should define a property to
distinguish
these cases. In WebKit's IDL we have the overly verbose
[ConvertNullToNullString] extended attribute for the first case (we
internally distinguish null string from empty string and I think
there
may be a tiny number of APIs that actually treat null and empty
differently). I am not sure which of these behaviors [NoNull] applies
to.
[NoNull] is meant to mean that null values won’t get passed
through, and
instead have to be treated the same as a value of whatever is inside
the
valuetype<>. Thus for DOMString, you’d get the normal
stringification
behaviour.
What’s the distinction between a null string and the null value?
Is the
null string just a way to force the null value into your string type,
internally?
It's not generally a meaningful distinction. Our string type
internally distinguishes empty and null strings. JS strings do not
have such a distinction, and null is not a valid instance of the
string type. Both typically act the same as the empty string, but a
very few places may check specifically for null string basically as a
hack to let JS null pass through a string-typed argument.
We have similar extended attributes for IDL method return values or
attributes that are nominally DOMString but may return other values
such
as null, or occasionally undefined,
I think because DOMString is actually a
valuetype<sequence<unsigned short>, a null value is allowed.
Well, JS is an odd duck here. It does not have an instance of the
string type, but it does have a null value (of a different type) and
dynamic type conversion and a weird rule for how null is converted to
string.
I guess what NoNull is saying is that null should stringify according
to JS rules, yielding "null", with the default assumption being that
DOMString parameters in IDL may take JS null. But NoNull does not seem
like a very clear way to express that idea (at least to me, as an
implementor more familiar with JS and DOM internals than with the
details of OMG IDL).
Also, notwithstanding the polite fiction that DOMString is a
valuetype<sequence<unsigned short>>, in real bindings it is treated as
a custom type that matches the native language's string type. So I
would not read too much into its theoretical IDL definition.
or in at least one crazy case, boolean false (thanks to whoever
designed queryCommandValue).
Maybe in crazy cases like that the return value should be │any│?
For our bindings code at least we prefer to be specific, since |any|
without additional knowledge of the actual types possible would
require hand-coding.
Regards,
Maciej
