It is amusing... a version 2.0 of a language spec admits that there were things and behaviors that were left undefined or unimplemented in the previous. Amusing that the thing they forgot was an implementation of UndefinedObject (nee nil). :)

Smalltalk got this right from the beginning. Any decent language reifies nil real fast. Every time I work for a while in non-nil-modelling languages, I always find myself asking, "how do people code with this crap?"

Comment on Undefined by alan knight

Note that programming language "nil" and database "null" are emphatically not the same thing.

I just think SQL's null is the reason behind the addtion of Nullable Type to C# 2.0.

No coincidence, I submit, that C# 2.0 is aligned with Yukon (CLR in the database).

I'd like to hear if there's another rationale.

Comment on Not impressed by Rich Demers

So why are nil and null not the same thing? They both mean "there ain't nutin here!" True, but Alan is still right because null and nil are at different levels of abstraction -- at least that's how I think about it.

A database null is at the same level as you find other database types and at the same level that you find java primitive types. These are strings of bits that only have meaning in terms of semantics imposed on them by external entities like compilers and databases. They have no intrinsic behavior and therefore no intrinsic meaning. Take the same string of bits and move it into a different database field or java variable, and its meaning changes completely.

In contrast, nil (at least Smalltalk's nil) is an object whose semantics is defined by the operations defined by its class (class UndefinedObject in Smalltalk). Take an object and move it into a different OO program variable and its semantics remains the same.

An object is represented as a string of bits, but its internal state is encapsulated by a defined set of methods and that makes it something more than just bits. Objects have emergent properties that don't exist in simple bit strings.

So if there are two levels of abstraction in programing systems, are there more, still higher levels? What might be the properties of the entities at the level above objects. And how might the creation and use of entities at that level affect the discipline of programming?

Comment on Re: Not impressed by alan knight

I agree with Patrick's conjecture as to why they're putting null in C#.

My reasons for saying they're not the same are nothing so vague as levels of abstraction. They don't behave the same way. A database null represents the absence of a value, or an unknown quantity, not a known but nil thing. So for example, if I have two database rows whose addresses are both null, a.row = b.row is false, whereas in pretty much any programming language it would be true. Of course, a.row ~= b.row is also false. SQL's NULL is much more like a floating point NaN than it is like a nil.

You might not think this is all that significant. I think it is, and it's subtle enough to bite you in unexpected ways. Most programmers really don't internalize a=a ==> false very well.

Take a look at http://nullabletypes.sourceforge.net/

"NullableTypes for .NET are a very reliable and efficient version of built-in value-types that can be Null. NullableTypes pass more than 800 differents test cases and have close-to-optimal efficiency as built-in value-types. They may be used every time you need to store a Null value in a .NET built-in value-type."