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.