I completely agree:
p foreach {
myThing
}
is ever so much cleaner and easier to follow compared to
if (p != null) {
myThing
}
It's, frankly, a breath of fresh air.
On Friday, July 6, 2012 5:05:51 PM UTC+1, KWright 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 view this discussion on the web visit
https://groups.google.com/d/msg/javaposse/-/mwBCMLE9cG4J.
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.
