This solution suffers from what we typeful programmers call “Boolean blindness”: https://existentialtype.wordpress.com/2011/03/15/boolean-bli... . When you compute a bit, what you are actually interested in is the meaning of the bit, which isn't included in the bit itself. For example, if the bit is set, then “x” is less or equal than “y”; if it's unset, then “x” is greater than “y”.
> Pattern 2: Switch to Polymorphism
Dynamic dispatch (what the author wrongly calls “polymorphism”) can be used for open-ended case analysis. But it suffers from two drawbacks: (0) Unless you have multimethods, case-analyzing two or more values at the same time is a bitch! (1) Even if you do have multimethods, the open-ended nature of this whole business makes static exhaustiveness checking (making sure that no case is missing) impossible.
> Patte[r]n 3: NullObject/Optional over null passing
Null objects are still falling back to pattern 2, and optionals are severely underpowered in languages without pattern matching and compile-time exhaustiveness checks. For instance, one of my favorite patterns is implementing operations (say, “merge”) on non-empty collections, then extending them to possibly empty ones:
(* pe = possibly empty *)
datatype 'a pe = Empty | Cons of 'a
(* extend a merge operation on non-empty collections
* to possibly empty ones *)
fun pointed _ (xs, Empty) = xs
| pointed _ (Empty, ys) = ys
| pointed op++ (Cons xs, Cons ys) = Cons (xs ++ ys)
fun merge (xs, ys) = ... (* possibly complicated *)
and mergePE args = pointed merge args
How do Java-style optionals help?
> Patte[r]n 4: Inline statements into expressions
This only makes the problems associated to Boolean blindness even worse.
> Pattern 5: Give a coping strategy
What if there is no sensible default value? Just... no.
---
What you really need is algebraic data types, pattern matching and exhaustiveness checks.
> Pattern 1: Boolean Params
This solution suffers from what we typeful programmers call “Boolean blindness”: https://existentialtype.wordpress.com/2011/03/15/boolean-bli... . When you compute a bit, what you are actually interested in is the meaning of the bit, which isn't included in the bit itself. For example, if the bit is set, then “x” is less or equal than “y”; if it's unset, then “x” is greater than “y”.
> Pattern 2: Switch to Polymorphism
Dynamic dispatch (what the author wrongly calls “polymorphism”) can be used for open-ended case analysis. But it suffers from two drawbacks: (0) Unless you have multimethods, case-analyzing two or more values at the same time is a bitch! (1) Even if you do have multimethods, the open-ended nature of this whole business makes static exhaustiveness checking (making sure that no case is missing) impossible.
> Patte[r]n 3: NullObject/Optional over null passing
Null objects are still falling back to pattern 2, and optionals are severely underpowered in languages without pattern matching and compile-time exhaustiveness checks. For instance, one of my favorite patterns is implementing operations (say, “merge”) on non-empty collections, then extending them to possibly empty ones:
How do Java-style optionals help?> Patte[r]n 4: Inline statements into expressions
This only makes the problems associated to Boolean blindness even worse.
> Pattern 5: Give a coping strategy
What if there is no sensible default value? Just... no.
---
What you really need is algebraic data types, pattern matching and exhaustiveness checks.