3 ms·

This view isn't without criticism though. http://www.alternativetech.com/publications/copper.pdf http://www.alternativetech.com/publications/copper.pdf Edit: "

This view isn't without criticism though. http://www.alternativetech.com/publications/copper.pdf http://www.alternativetech.com/publications/copper.pdf Edit: "Logicians have proved that a large class of MVLs are not truth-functionally complete[.] They have also proved that if such an MVL is made complete (for instance, by adding the Slupecki T-function), it becomes inconsistent! Therefore[,] we can have either truth-functional completeness or consistency, but not both."

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 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.

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 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.