Common superclass for Optional<T> and primitive variants?

[Paul Benedict]

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