Optional -> OptionalResult

[Clayton Wohl]

Why would "Map<Optional<List<Optional<String>>>" be more of a concern than
any other ridiculous combination of generics nesting? How about
List<Vector<Stack<AtomicReference<ThreadLocal<Integer>>>>>?

Usually, devs don't nest optionals inside of lists/maps. I'm sure it will
happen in some edge case, but in the Scala code or the Functional Java code
bases I've worked in, people do not do that, just like they don't do lots
of other crazy combinations of generics that are technically possible in
Java 5+.

For the name, I like Option/Optional, however, that's a relatively minor
detail and I will be happy with whatever the JDK team chooses.

Stephen, the reasoning for an Optional type with map/flatMap/forEach
functionality is very convincing and I don't believe it's appeal is limited
to elite FP experts, which I am definitely not. I've seen lots of junior
Java devs appreciate the same functionality in Functional Java. Your
opposition to this does not seem to have a grounding in reason.

BTW, the new date/time library you've worked on looks amazing. I've been
using the plug-in version in my personal projects for years, and I am
excited to see it broadly adopted into the core JDK 8.


On Tue, Jun 4, 2013 at 10:13 AM, Stephen Colebourne
<scolebourne at joda.org> wrote:
> Optional is, and will continue to be, a key debating point for those
> arguing for more FP. The pressure to make it more powerful will
> continue, especially given similar named features in other languages.
>
> Meanwhile I continue to fear Map<Optional<List<Optional<String>>> and
> the like. The generics type system in Java simply isn't good enough to
> be doing anything like that, even if it were remotely desirable.