Common superclass for Optional<T> and primitive variants?

[Brian Goetz]

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
>