Common superclass for Optional<T> and primitive variants?
jed.wesleysmith at gmail.com
Tue Mar 5 11:39:24 PST 2013
If i were implementing, I'd probably first want to know the use case for such a thing.
Firstly I'd ask what a Stream of optional things means – why do you produce a nothing from your stream and what might you do with it? Another way to think about an optional thing is that it is a collection of zero or one elements, and a Stream is a collection of potentially infinite number of elements. So then, I have (conceptually) a Collection<Collection<T>>, which would be easier to deal with if it is simply flattened down to a Collection or Stream of Ts and dropped the nothings. The only way I can think it would mean something is if the index were significant and should be preserved.
The second question is how you'd deal with dispatching on an optional that may contain a reference type or a primitive. Given that Java contains no common super-type, you need to provide the specialised methods for each primitive – there is no way to cleanly do this in Java.
Last is just an observation, this is not really a heterogeneous collection. A true HList will be typed with each element's type, not simply the least upper bound super-type of all elements in the collection. Note that this makes infinitely recursive HLists impossible in most current (strict) type systems.
On 06/03/2013, at 1:52 AM, Paul Benedict <pbenedict at apache.org> wrote:
> I'd still like to hear feedback on a common superclass. That was the main proposal. Right now, there's no way to return a mixed stream of optional objects and optional primitives. I believe the mixture -- the so-called heterogeneous collection -- is not a use case that should be excluded.
More information about the lambda-dev