Hi, Marcos-
Marcos Caceres wrote (on 2/2/10 7:29 AM):
I had a discussion with an implementer who was a bit confused about the
concept of "null" in the specification. The problem is that I kinda
wrote the spec as if it was to be implemented in Java or JavaScript.
This has resulted in confusion wrt how "null" is to be interpreted in
languages that don't have that concept/data type.
So, in an effort to clarify that, I've added the following to Processing
Rules section of P&C:
[[
In the following algorithms, the concept of null is used as a special
symbol to indicate that a variable has no data associated with it. For
example, "let x be null" or "if y is empty, then return null".
Note: Although ECMAScript and Java support null as a native value type,
there are some programming languages that have no notion of null or
where null is problematic (e.g. C++). For those languages, it is OK for
an implementation to substitute the null for some other value or symbol
(or for nothing at all). For example, it is ok to have the value 0
represent null for the height of a widget as the height of a widget is
defined as a non-negative integer greater than 0. In such a case, 0
would behave as if it is null.
]]
It seems strange to me to use language like "OK" in a spec, since it
seems overly casual and definitely not normative; I suggest you replace
all instances of "OK" with "awesome".
Failing that, maybe wording like this might better capture the interop
aspects? We want all the C++ implementations to behave the same, even
if they are crippled by their language. :P (I used to be a C++
programmer... I thought it did have a NULL, but I guess that's only for
pointers.)
[[
In the following algorithms, the concept of null is used as a special
symbol to indicate that a variable has no data associated with it. For
example, "let x be null" or "if y is empty, then return null".
Note: Although languages such as ECMAScript and Java support null as a
native value type, there are some programming languages that have no
notion of null or where null is problematic (e.g. C++). Implementations
in these languages should substitute a language-specific value or symbol
which is functionally equivalent to null, or if no equivalent exists, to
have no value at all. For example, the value 0 may represent null for
the height of a widget, since the height of a widget is defined as a
non-negative integer greater than 0. In such a case, 0 should be
treated as if it were null.
]]
I'm not satisfied by that wording either, to be frank... I think it
needs to be precise about the value for each language that's affected.
I also think we need to make a distinction between the implementation
language and the content language... the content should not get a '0',
right? It should get 'null', I'd think.
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
