blog.jj5.net (2003 to 2005)

While I'm waiting..

Fri Jan 30 21:33:00 UTC+1100 2004

Categories:

Just 'waiting by the phone' for a mate to call, so since I've got a minute I thought I'd mention what I'm thinking about at the moment.

I've been ranting about NULL a fair bit lately, and I'm still thinking about it.

I need to model three 'types' (or maybe 'states' is a better word, that's what I'm thinking about) of keys.

Say I have a Project table, like this {Id, PersonId, Name} and PersonId is a nullable foreign key to Person {Id, Name}.

Project.PersonKey is modelled with a PersonKey. I define a singleton PersonKey.Null and possibly an instance property PersonKey.IsNull that checks itself against this type. PersonKey is immutable. PersonKey overloads == and !=. PersonKey overrides Equals() and GetHashCode(). The thing that I'm really having trouble deciding at the moment is how PersonKey.Null.Equals(PersonKey.Null) should behave. Every part of me is screaming that this should always return false, even though the reference is the same.

The thing is that the PersonKey object is specifically designed for use as a 'keying' mechanism, meaning that these object _will be_ used in hash tables. If I define PersonKey.Null.Equals() to return false as above, then I will 'lose' objects if I try to key them with this value. Making this value illegal as a key, while all other instances are supposed to be keys..

Anyway, there is another thing that's hard to, but my mate just called.. gtg.

John.


Copyright © 2003-2005 John Elliot