Re: [widgets] Null in P&C

Hi Doug,

Doug Schepers wrote:
> 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".

heh, don't tempt me:) I'm a big advocate of the clarity that comes with 
the use of colloquialisms. Clarity above all else - specially at the 
expense of fancy words, long sentences, and excessive jargon. That's not 
to say I'm a good writer, but I try my best.

> 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.)

I honestly don't know; I'm just going on what this says:
http://www2.research.att.com/~bs/bs_faq2.html#null

> [[
> 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 included your text into the spec.

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

I know what you mean, and as you can understand, it's a little bit more 
complicated than that: null sometimes plays the role of a flag, as is 
the case with widget@width being null which would trigger the user agent 
to use a "lacuna" value defined else where [1]. What I mean to say is 
that in most cases, null could be substituted for the word "banana" and 
the behavior of the spec would not change. Anyway, I don't think I want 
to spent much time on this because I think with the above text serving 
as an explanation this should all be OK and awesome.

The proof that people are able to correctly interpret the spec is 
evident by the growing number of implementations that are claiming 
conformance. Of course, we are putting trust in individual implementers 
submitting their own results - but we are hopeful that we (the WG) will 
be able to independently verify that implementations really do conform 
before progressing this document to PR.

[1] http://berjon.com/blog/2009/12/xmlbp-no-lacunae-values.html

Received on Wednesday, 3 February 2010 09:12:44 UTC