Stop using, opt match { case Some(x) => f(x); case None => y } Stop using, http://opt.map (f).getOrElse(y) Use, opt.fold(y)(f) I feel like I'm very late to this party.
-
I actually kind of disagree. map(f).getOrElse(y) clearly conveys the intent of your code and makes it easy to understand for other people. fold(y)(f) doesn't. In my case at least, I always have to do the mental gymnastic of "oh, this means map.getOrElse"
But wouldn't you say that map...getOrElse is itself halfway between the pattern-match to the fold in terms of clarity? I think the difference is that right now we're much more familiar with maps than folds, especially when the context is an Option.
-
-
Honest question though: is that a proper fold? In my mind, fold is heavily linked to monoids: - takes an "empty" value - takes a merge function that's basically a monoidal append This is not what Option.fold does. Am I misunderstanding what fold is?
-
Your mixing `Foldable` (the typeclass) with the algebraic fold, the later is basically isomorphic to pattern matching. The fact that folding on a List is recursive, is incidental (because the type itself is recursive), not the opposite.
- Show replies
New conversation -
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.