Optional != @Nullable

[Olexandr Demura]

Your last example shows me only disruptiveness of primitives in java
type system.
When we move your sample to objects, we'll have elvis more readable
(and effective) again:
return getOptionalValue1()
  ?.times(getOptionalValue2())
  ?: getDefaultValue(); // lazy call

External variable assignment in `for`-block. Is that functional way?
Should be declare any monad Iterable? (and there are plenty of them)
Lets do the same to previous code sample:
Optional<String> address(Session session) {
  Optional<String> r = optional(null);
  for (SocketAddress socketAddress
      : optional(session.getIoSession().getRemoteAddress()) {
    for (InetAddress inetAddress
        : optional(socketAddress.getAddress() {
      r = optional(inetAddress.getHostAddress()); // may be simply `return`?
    }
  }
  return r;
}
Or should we request natural haskel `do`-blocks next instead of those
weird elvis-ops?

Also, the was mistake in first letter - your Partial broke LSP.
Partial should not extend but have Filter.
Partial should not extends Map but EitherMap<Result, Expection> or
something like that.

2012/9/30 François Sarradin <fsarradin at gmail.com>:
> Hi Artur,
>
> Indeed, for the traversing problem, the elvis operator is more
> readable. But I think there are circumstances where flatMap solves
> problems that elvis operator doesn't. Suppose you have two methods
> getOptionalValue1 and getOptionalValue2. Both return an
> Optional<Integer>.
>
> Optional<Integer> result = getOptionalValue1().flatMap(
>     x -> getOptionalValue2().flatMap(
>         y -> optional(x * y)));
> //
> return result.getOrElse(defaultValue);
>
> The nice thing here is that you have a safe access both by what is
> returned by getOptionalValue1 and getOptionalValue2.
>
> Notice that if you have no flatMap operation, there is another nicer
> solution. Suppose that Optional implements Iterable. You can express
> the previous expression like this:
>
> int result = defaultValue;
> //
> for (int x : getOptionalValue1()) {
>     for (int y : getOptionalValue2()) {
>         result = x * y;
>     }
> }
> //
> return result;
>
> Here, I use the for loop to destructure two Optionals... And Java does
> it naturally and safely! So you can execute the inner operation
> without fear of NPE, assuming Optional doesn't consider null as a
> possible value.
>
> And if you don't have no flatMap nor Optional implementing Iterable,
> you can emulate flatMap by using map operation on an Optional of
> Optional. But it is uglier.
>
>
> Regards,
> François Sarradin
>
>
> 2012/9/30 Artur Biesiadowski <abies at adres.pl>:
>> On 30/09/2012 10:13, Jed Wesley-Smith wrote:
>>>
>>> Option<String> address(Session session) {
>>>    return optional(
>>>      session.getIoSession().getRemoteAddress()
>>>    ).flatMap(socketAddress -> optional(socketAddress.getAddress())
>>>    ).flatMap(inetAddress -> optional(inetAddress.getHostAddress()));
>>> }
>>
>> Is it really more readable than
>>
>> return session.getIoSession().getRemoteAddress().?getAddress().?getHostAddress();
>>
>> ?
>>
>> Given java history and existing libraries, I think that repurposing null
>> as None, assuming non-null contents of collections for most of
>> lambda-empowered libraries/utilities and providing few operators for
>> safe traversal (?. and ?: at least) would be a lot more useful solution.
>>
>> Regards,
>> Artur Biesiadowski
>>
>