Lol, thanks for the vote of confidence! Been thinking about getting back on the blog scene, even been pushing zeebox into doing something formal, watch this space... On Jul 6, 2012 5:32 PM, "Ricky Clarkson" <[email protected]> wrote:
> I like your ideas and wish to subscribe to your newsletter. > On Jul 6, 2012 1:06 PM, "Kevin Wright" <[email protected]> wrote: > >> More normally, you'd just map over your option: >> >> val p = Some(person) >> p foreach { myMethod } >> >> >> This works precisely because you're keeping the optional nature of such >> constructs away from your functions, allowing them to just get on with >> their job ab not have to muck about checking for null and suchlike. >> >> You DON'T weave monads through functions, you weave functions through >> monads. This is the crucial distinction between Option/Maybe and >> nullability, but it can also be a tricky concept until your default mental >> model of functions is that they're first-class entities in their own right, >> and can be freely composed, manipulated, passed as arguments, etc. >> >> So it's your Option[Person] that accepts your method. Not the other way >> around. >> >> >> On 6 July 2012 16:47, Cédric Beust ♔ <[email protected]> wrote: >> >>> On Fri, Jul 6, 2012 at 4:28 AM, Reinier Zwitserloot >>> <[email protected]>wrote: >>> >>>> >>>> >>>> On Friday, July 6, 2012 1:12:18 PM UTC+2, Dale Wijnand wrote: >>>>> >>>>> On the fly I can't think of a reason to return a List<Option<T>>, >>>>> that's just ridiculous. >>>>> >>>>> >>>> Why is that ridiculous? If I have a method which emits an Option<T>, >>>> and I have a list of inputs and I run a map operation, I'll get a >>>> List<Option<T>> out. Either Option is part of the type system (which also >>>> means it can be used in generics too), or it's not. There's no halfwaysies >>>> on this, IMO. >>>> >>> >>> Right, it's not ridiculous. The overall idea is that once you start >>> manipulating monadic values and you are using a language whose syntax and >>> libraries supports monads pervasively, you are better off keeping these and >>> working with them than flattening them. Note that I abstracted away from >>> Option: such API's don't accept just an Option<Person> in their API but a >>> Monad<?>, which Option happens to satisfy (and a bunch of others). >>> >>> In Java, you will most likely need to flatten more often because all the >>> API's accept non-monadic values, e.g. your API accepts a Person, not an >>> Option<Person>, so you have to extract the value before calling that API. >>> >>> -- >>> Cédric >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Java Posse" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> > -- > You received this message because you are subscribed to the Google Groups > "Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
