Daniel quite rightly points out that nullable-types (i.e. Nullable<T>) has been a topic of discussion for the last couple of days. It all started when I asked a question about the support for nullable-types in the data-set designer. Others chimed in about their concern about nullable-types and we were off and racing.
Some people thought that they smell bad – and as experienced developer types we’ve learnt to trust our sense of smell, but pushed past that to really try and draw out how you can avoid their use but also where they can really help out. Obviously nullable types help traverse the SQL and .NET type systems so we spent quite a bit of time talking about nullable values in databases.
Luke Drumm made an excellent point that NULL != a third value. For example, lets say you have a column in a table that accepts a single character – either M or F to define the gender of the subject then you may as well include a value U for unknown – this maps quite well to the .NET type system because the value type System.Char can always have its value populated.
But flexible data-types like string fields in databases are flexible enough to define a concrete “I don’t know value” but some other data-types can’t. Greg Low pointed out a great example with date/time fields and put it in the context of reporting functions where most reporting tools for relational databases are NULL-aware and treat them specially (a good thing), where as if you defined a magic value for the date/time field it would actually be included in any aggregate calculations (I’m paraphrasing and elaborating here Greg so forgive me if I got this wrong).
Some folks still weren’t convinced but then Martin piped up and pointed out that nullable-types might make it easier to bridge the .NET and XML type systems in web-services scenarios. I think that helped put the usefulness into context for some people but I am sure that they will approach nullable types with some reservations (not necessarily a bad thing).
But there were some common themes here. Nullable-types essentially loosen up the .NET type system’s handling of value types and its useful at the cross over between things like SQL server and XML (I am sure there are more).
They are also useful when the particular data-type you are dealing with doesn’t really have a concept of a “unpopulated” value and NULL values are the standard fall-back position.
Anyway – it was a really interesting discussion and it has actually helped me quite a bit with my TechEd preparation – I’ll have some useful ammunition if a question comes up in the nullable-types section of my talk. Thanks guys!