Common superclass for Optional<T> and primitive variants?

[Jed Wesley-Smith]

On 5 March 2013 09:45, Stephen Colebourne <scolebourne at joda.org> wrote:
> I fear that developers, egged on by misguided Scala folks

Your provocation is misguided. As any Scala developer will tell you,
proper use of Option has all but eliminated NullPointerExceptions from
anywhere but the boundaries of Scala/Java interaction.

> will try to
> use Optional everywhere to wrap nulls. In reality, null is a basic
> language feature of Java that cannot be wished away. Even with
> widespread use of Optional in an application, NPEs will still happen
> (contrast with the solutions in Fantom/Lotlin). All the existing
> libraries manage nulls as NPE or leniently, and would not be aware of
> Optional (nor should they).

Sigh. Interop with null using library becomes a matter of identifying
what produces null (ie. via the existing non-typesafe manner for
instance in comments, or annotations) and wrapping it an Option
producing method.

> More generally, generics get very wordy and unreadable once nested too far:
> Optional<Map<String, Optional<Map<Integer, Optional<Double>>>>

This is a straw-man. A Map<A, B> is-a partial function from A => B, so
making B an Optional<B> means that you'd have map.get return null for
a non-existent A, or if there's a get form that returns Optionals for
non-existent mappings, it would return an Optional<Optional<B>>. In
other words, PartialFunction<A. B> extends Function<A, Option<B>> and
Map<A, B> extends PartialFunction<A, B>.

That said, the point of Optional and its ilk is to encode in the
type-system the optionality of the result. This is a good thing, the
type tells us how we can access the data safely. This is a very good
thing.

cheers,
jed.