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.

Reply via email to