Loose ends: Optional

[Sam Pullara]

Awesome. fromNullable was the last piece that I think that Optional was missing. On the forEach stuff I'm ok with a different method name — maybe onPresent? I don't think it is something that will be used a lot.

Sam

On Jun 10, 2013, at 5:05 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> I got confirmation from the Fugue maintainers here.  They confirm that the null behavior of map() is as intended, and also that returning null from the flatMap function would be an outright bug, but they chose simply to not enforce it -- but also allowed as how they liked the idea of enforcing it.  So, I think what we've got is in the same spirit.
> 
> I don't follow your arguments about why flatMap "requires" fromNullable, but given that this is a feature that has also been widely requested, if that will bring this sad story to a close, then I'm good with it.
> 
> On 6/10/2013 3:14 PM, Brian Goetz wrote:
>>> For flatMap, the rationale for "throw on null return" here is that:
>>> Optional-returning methods should never return null (they should be
>>> total functions, they can always return either a present or empty
>>> optional), so a null return should be considered a programming error
>>> (like trying to unbox the "null" Integer.)
>>> 
>>> For map, it is different; it is entirely reasonable to imagine that the
>>> mapper is a partial function, so, just like with computeIfAbsent, we
>>> should interpret a null return as "no result".
>>> 
>> 
>> Looking at the Fugue implementation, it differs slightly.  Their map()
>> treats null-return as empty, and their flatMap simply returns null if
>> the mapper returns null.  I am fine with being consistent with Fugue
>> here; I think the lambda passed to flatMap should never return null, but
>> we don't have to go out of our way to check it if we don't want.
>> 
>> I've got a query into the Fugue guys to see if they're happy with that
>> after having used it for a while.