The alternative is to create new opaque types that are boolean underneath and rely on constructors.
-
-
-
Sometimes the types aren't opaque for the client. In this case, the only client was a recursive call, and I wanted to be sure I wasn't getting the order of arguments subtly wrong.
- 3 more replies
New conversation -
-
-
Same in Scala. But there's a better solution. Don't use Boolean args.
-
Also, the advice of making non commutative variables of the same type applies to all types, not just the booleans I had to distinguish in the case at hand. Exception when the function is so well known or often used, with few enough arguments, that position is unambiguous.
End of conversation
New conversation -
-
-
Do you also avoid numbers without dimensions, integers without explicit lower and upper bounds, floating-point numbers without explicit precision requirements, data without provenance information, etc. ?
End of conversation
New conversation -
-
-
A nice post on booleans in api design ishttps://ariya.io/2011/08/hall-of-api-shame-boolean-trap …
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
I’m taught to write self-explaining (self-documented code) by any mean. Thanks for yet another argument pro it ;)
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
Read my blog!