3 ms·

I think the actual observation of the article is that many booleans are guards for the presence (or validity) of a value, and that modelling those as Optionals

by mdpye 5y ago

I think the actual observation of the article is that many booleans are guards for the presence (or validity) of a value, and that modelling those as Optionals binds the result of the guard and the applicable value in a way which can prevent later mistakes. It's not arguing at all booleans should be treated this way.

layer8 5y ago
That makes more sense, although I can’t say that "many booleans are guards for the presence (or validity) of a value" matches my experience.
- mdpye 5y ago
  Many of those booleans aren't necessarily named. Any "is(n't) null" check on a nullable includes a boolean expression. That's quite a few booleans right there. Using an optional (and accessing it with either fmap or a match expression) removes the value from the scope of the "wasn't present" branch, eliminating a possible source of mistakes. Using an optional with an isPresent test does not. And you see that boolean pop up again in the return of that method. I think that's what they're getting at.