Common superclass for Optional<T> and primitive variants?

[Stephen Colebourne]

I fear that developers, egged on by misguided Scala folks, 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).

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

Renaming Optional as OptionalResult clearly delimits the type to be
about declaring optionality *in a result*. Users would be far less
willing to use that type other than as a return type.

Users wanting a more general Optional type can still use Guava, or similar.

Stephen


On 4 March 2013 22:22, Paul Benedict <pbenedict at apache.org> wrote:
> Stephen, if you don't mind, could you describe the overuse/misuse that I am
> (likely) describing? I guess that's what you were implying. I am interested
> in hearing your design thoughts. -- Paul
>
>
> On Mon, Mar 4, 2013 at 4:19 PM, Stephen Colebourne <scolebourne at joda.org>
> wrote:
>>
>> I continue to think that this class has more potential for
>> overuse/misuse than others being added. Renaming it to OptionalResult
>> would greatly reduce that risk and make the rationale clearer.
>>
>> Stephen
>>
>>
>> On 4 March 2013 22:04, Paul Benedict <pbenedict at apache.org> wrote:
>> > I think Optional would be useful for data providers that contain
>> > nullable
>> > types. There are lots of frameworks out there (like Spring JDBC) that
>> > provide simple query operations and return a flat collection of values.
>> > Right now, all those values are boxed -- the specific OptionalXXX
>> > variants
>> > could be useful to prevent that boxing.
>> >
>> > Furthermore, if Optional was also an interface, JDBC could take
>> > advantage
>> > of implementing the interface. Maybe Optional::isPresent() could
>> > delegate
>> > to ResultSet::wasNull()? There would also be the opportunity for new
>> > ResultSet methods that return a List<Optional<?>> objects.
>> >
>> > Paul
>> >
>> > On Mon, Mar 4, 2013 at 3:26 PM, Brian Goetz <brian.goetz at oracle.com>
>> > wrote:
>> >
>> >> Can you explain what you see as the benefit (to offset the cost of an
>> >> additional public type)?  Where would the supertype show up in APIs?
>> >>
>> >>
>> >> On 3/4/2013 3:47 PM, Paul Benedict wrote:
>> >>
>> >>> I think it would be a good idea to give the four Optional classes a
>> >>> common
>> >>> super class. This would allow heterogeneous collections of OptionalXXX
>> >>> objects to be returned.
>> >>>
>> >>> I can understand why Optional<T> is NOT the superclass so that
>> >>> unnecessary
>> >>> boxing is avoided. That's not what I'm suggesting. It could simply be
>> >>> a
>> >>> marker interface, if necessary, but I think equals/hashCode/toString
>> >>> could
>> >>> be shared code.
>> >>>
>> >>> If the current Optional<T> was renamed to OptionalObj, then the name
>> >>> Optional would free up for the common superclass.
>> >>>
>> >>> Paul
>> >>>
>> >>>
>> >
>>
>