Common superclass for Optional<T> and primitive variants?

[Paul Benedict]

Yes, I see that. However, unless my understanding is incorrect, Streams may
not contain nulls, right? That's why Optional exists to act as a sentinel
for a missing value? If true, then I amend my suggestion for data providers
-- not to return collections of Optionals, but a stream of Optionals.

On Mon, Mar 4, 2013 at 4:45 PM, Stephen Colebourne <scolebourne at joda.org>wrote:

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