3 ms·
I was merely adding context. The arguments mostly boils down to - the mathematical rigor, as you suggest, which besides the issue of contradictions also intro
by CuriousSkeptic 11y ago
I was merely adding context.
The arguments mostly boils down to
- the mathematical rigor, as you suggest, which besides the issue of contradictions also introduces problems for the implentattion of things like query optimization.
- non-null solutions are possible, f.ex. normalization, which besids avoiding the null-issue also comes with other benefits.
However, I'm not sure Nullable<T>, is problematic in the same sense. It is, after all, an explicit value domain, and not part of any logic at all. Notice how the debate about relational systems doesn't talk of a Boolean value domain (MSSQL doesn't even have a Boolean type, only a single bit number type) but of the predicate logic resulting from existing and non-existing rows.
I guess a comparable situation would rather be, if you have a Nullable<T> where T:class, how do you treat the difference between boxed and unboxed nulls?
In, Scala, f.ex., it's perfectly valid to have Some(null) != None, which means you need to handle the null value even for non-None values.