Question

Null Boolean

1

Is there a legitimate reason why boolean values cannot be null? In Java, there are classes designed, object wrappers, for the primitive types. For example, the boolean type is called Boolean. So why then, as integers (int) are transformed into the Integer class, aren't booleans transformed in the same way? Having a non-nullable field type does not make much sense to me from a programming or data structure perspective (unless the field is required). Does anyone know why Mendix went this route?

asked 2014-03-31

Jason Braswell

4 answers

Sebastiaan van den Broek · Answer 1 · 2014-04-01

I don't remember áll the design decisions behind this, but we did change this at some point in time because there were strong reasons for it. One of them was that all exclusive splits also would need a null exit rather than just true/false. Another is that there are always other systems that can either handle or not handle null Booleans, so there is always a system where integration needs a little more work.

Jason Braswell · Answer 2 · 2014-04-01

Null values do not mean the same as a default boolean value. Having a nullable field distinguishes whether a user entered a value for a field or not. From a reporting perspective, this is very important. Additionally, many web services return nullable boolean fields. As in the aforementioned example, null has a completely different meaning from a primitive's default value.

I find it odd that I have to explain why this is important, or why there is a null construct in OOP or database schemas. To me, there needs to be an overwhelming support to go against current constructs and ideas for OOP. I did not come up with them, but surely you can understand why there are such things as null references. For every other primitive type this is allowed, so I think their reasons are just as valid as the ones for the Boolean class.

Michel Weststrate · Answer 3 · 2014-04-02

in OOP null values are primarily used for references, not for primitives. In Java I never use nullable primitives except when I need generics, which is imho more a flaw in language design than a sensible construct (a lot of generic collections will actually throw an exception if you put some null value in it). If you need a nullable boolean, just go for an enumeration, that does conceptually excatly the same and makes sure that you handle null value everywhere nicely, which would be a big burden if you had to do that for every normal boolean.

To me a boolean is just a single bit. And single bits can only be true or false. Everything that is supposed to express more than two different states should not be modeled / programmed as a boolean in any language, because it sets every reader of your code / API completely on the wrong foot. Thats my 2 states,....errr cents.

Acellam Guy · Answer 4 · 2014-04-03

Even if we were not looking at Boolean Type of data but any other of data; String,Integer,etc. NULL simply means that the entity or field has not been tempered with.it indicates that a data value does not exist. For example if the field was a boolean value that is supposed to indicate to us if management made a decision about selling coffee, then a true or false value would indicate the managements stance and NULL would show that they didn't respond at all.

Every system has its own limitation and i agree that you could use other data types such as enums for this and perhaps we need to think in that direction in advance when we are thinking of integration with mendix