I don't like Nullable<bool>. The cognitive dissonance is louder and more dissonant than a Sepultura guitar solo. [3'00]
A boolean is defined as: "Of or relating to a data type or variable in a programming language that can have one of two values, true or false."
Two. Deux. Zwei. Dos.
TWO!
Not three.
But that is what exactly Nullable<bool> is. True, false and null. Three states.
What does null mean? It's got to mean something. You're either pregnant or you're not. You can't have a third state. A light switch is either on or off.
If a light switch doesn't exist then it's potentially very dangerous. Almost as dangerous as having a nullable bool.
If it has three states, it isn't a bool.
4 comments:
If you only want 2 states why are you using a nullable bool? Why not use a bool?
@Jonathan I could be wrong, but I don't think I've used a nullable bool. It came up in conversation yesterday and I just thought I'd jot down why I don't like it as a concept.
I can think of three reasons for why someone might need a nullable boolean:
1. Databases allow boolean fields to be null. To correctly map between the database value and the in-program value, nullable booleans are needed.
2. A lightswitch can only be on or off, but it you haven't yet gathered data on its state, you do not know which. So it makes more sense to initialise the program's cached state of the lightswitch to null until its true state is read. That way any test of its on/ off-ness will fail until its real state is determined (which is the right thing to do).
3. Modeling Qbits. Qbits - and the sub-atomic particles upon which they are based - have three states: true, false and both. One could model Qbits with a nullable boolean. If one extended it with a test (f) that resulted in f(qbit) and f(!qbit) both returning true when null, then it would be a pretty good model (it wouldn't have the same speed advantages of real Qbit-machines though ;)
Of course away from these situations, it makes no real sense to use a nullable boolean. So don't. There are edge cases where it does make sense to use them though.
@David Arno
Point 1 does seem to be the canonical example. It's the one that is mentioned on the Nullable type page.
"For example, a Boolean field in a database can store the values true or false, or it may be undefined."
So yes, there could be some value if you have nullable bits in a closed/legacy database.
However, I would still argue that 'undefined' means something. This is confusing or at least something is confused. Why did the schema designer allow nulls in a bit field in the first place? What I think Bruce Boughton did was to use the nullable bool from the database, but then in the application convert it into an enum.
2. I think that for most domains, it is possible to structure the model in such a way that it would be fair when you haven't gathered data on its state, you could/should assume it is false.
3. As for this point, I'd rattle the tin where I keep the cat food. If the box moves then the cat is still alive. There is nothing, no lead, no quantum mechanics that would stop my cats from sensing that noise. ;-)
I do agree that they have their place. I'm just saying that they should be approached with extreme caution!
Post a Comment