Nulls

Thursday, October 20, 2005

Wesner Moise has a detailed and insightful post comparing how C# and VB.NET treat null values (System.Nullable).

I'm not taking sides here. I don't like that whole limbo value business, especially when null or empty or unassigned or undefined or missing or error or nothing or default become part of whatever language, along with operators and all, and considering that value-type vs. reference-type disconnect. Throw in empty strings, and listen to people talking about "null objects" or "null colors". It isn't like there is a generally accepted concept of "null" anyway (with only the details differing in various systems); it's rather that people have some vague idea about some limbo state, and they'll happily map any the above terms to it at random.

Let's not return to Variants. Let program logic be explicit.

On the other hand, we could apply management tools, that is, create the Limbo Value Management Framework. Yes, create an object-oriented, extensible architecture for managing limbo values. Why, one can think of other limbo states, like inherited (think of node properties in tree structures). The whole thing would be implemented as a generic struct, with a special field that points to an object providing the limbo state, implementing the necessary logic. Look here.

Of course, Limbo.cs is a joke. But it is somewhat interesting I think, in that it is a generalization of .NET's first approach to dealing with unknown values - having the singleton instance of System.DBNull as a special reference target. One difference is that more type information is availabe, because the Limbo type is both complex (one field stores a value, another references the limbo state, which need not necessarily be a singleton) and generic. Another difference is that the Limbo can be in any custom limbo state.

A more practical question is how to deal with null references (as with reference types). As Wesner Moise points out, the C# philosophy is to use System.Nullable as a means to bridge the gap between value types and reference types with respect to signalling non-existant values. In fact, that's the best semantic definition of null references. Therefore, the C# compiler warns when the System.Nullable generic is constructed with a reference type - null references themselves are just fine for that purpose, and they're strongly-typed as well. That line of thinking also explains the use of the null literal in C# and how boxing and unboxing works specially with regard to System.Nullable (not System.Nullable, but the value, if present, is boxed, or otherwise null is assigned).

Limbo, on the other hand, treats null references just like any other, non-limbo, value of the respective reference type: SqlNullState means the value is unknown, and even its existance may be known or unknown.