Common superclass for Optional<T> and primitive variants?

[Stephen Colebourne]

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
>>>
>>>
>