korona wrote:Using a Null Object instead of null only makes sense if that object can provide a meaningful implementation of all methods. Using a Maybe/Optional/etc. return type makes sense when an empty result is part of the semantics of your function.
You say you disagree on almost every point, then you echo what the article is saying about alternatives to 'null'. I am confused. To reiterate, the article is saying that these two patterns subsume every useful way of using 'null' while excluding the broken ways of using it.
korona wrote:In general that talk about "domains of primitive data types are too large" contains a lot of bullshit.So this function has 2^2 = 4 possible implementations. Perhaps we could write a test case for each one.
That is just totally stupid. I don't think I have to explain why.
Why is it stupid? Is it because a Boolean could be
korona wrote:It is standard practice to use -1, 0, 1 return values for comparison operations. Doing something else certainly violates the principle of least surprise. It is as bad as the famous "true", "false", "file not found" enum.
That's fine until someone discovers that they need to handle unordered values like floating-point NaN, and decides to do it by introducing a "-2" return value meaning "the arguments are unordered." They rewrite 20% of the compare-based library code to handle "-2" correctly, because that's the least-effort way to make their test cases pass. They update comments in half of the functions that they have modified. Now the comments don't correctly describe the code and it is unclear how some of the library functions should handle a "-2" value. (Do I have to decide whether sorting should put unordered values at the beginning, or put them at the end, or remove them from the list, or throw an exception?) I've had to deal with the outcome of this kind of codebase evolution, where it is unclear what program behavior should be correct because various people have put code together without thinking through the consequences.
You probably think that introducing that "-2" value after the fact is a bad way to do things. If your explanation for why it's bad is based on domain modeling or code contracts, you're effectively saying we should pretend we have a three-valued Ordering type, even though we really don't. By this point, you're agreeing with a substantial part of what the article is saying.