3 ms·
The last time I looked at this, most of the arguments were focused on mathematical rigor of comparing NULL to NULL. Are they the equal or not? (The RDBMS of O
by jasode 11y ago
The last time I looked at this, most of the arguments were focused on mathematical rigor of comparing NULL to NULL. Are they the equal or not? (The RDBMS of Oracle, MSSQL, etc don't all agree.) It doesn't matter which interpretation one favors, it will eventually lead to a logical contradiction.
If you took away the Nullable<T> concept to conveniently add 3-value logic to value types, the same philosophical problem still remains. If you force programmers to manually reinvent their own 3-value logic (e.g. manually add in an extra bool variable "HasValue" to signify whether another variable's content is "valid", you still have the same conceptual problem your pdf is grappling with.
- CuriousSkeptic 11y agoI 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.