4 ms·

>Surely it is true or false, but not null. If that's surely what you have, then you have a regular "bool" and not nullable "bool?". In C#, "bool" and "bool?"

by jasode 11y ago

>Surely it is true or false, but not null. If that's surely what you have, then you have a regular "bool" and not nullable "bool?". In C#, "bool" and "bool?" are not the same type. (Although C# provides some convenient implicit conversions that minimize tedious verbosity when working with both -- but that convenience also has the effect of blurring the lines. Nevertheless, they are different types.) A "bool" can represent 2-states. A "bool?" can represent 3-states: true -or- false -or- unknown/empty/indeterminate/invalid/etc. Your premise that I quoted is constrained to 2 states -- therefore use the 2-state type which is plain "bool". Unless you think nullable "bool?" as a syntax seems to defy some kind of airtight mathematical logic? What would be the alternative?!? Have everyone create a custom enum that with 3 enum values "{falsy = 0; truthy = 1; unknown = 2}"? Why would reinvention of those semantics in everyone's redundant code snippets be better than C#'s standard nullable "bool?"? (Another issue that may confuse the "null" discussion is the 2 separate concepts of "null": #1 is "null" as an indicator of pointing to invalid memory and #2 is "null" as deliberate semantic placeholders for application/business logic of unknown values. The #2 concept is what is modeled by C# nullable<T> and SQL database fields.)

CuriousSkeptic 11y ago
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.

by jasode 11y ago

CuriousSkeptic 11y ago

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.