(original) (raw)
I agree that we still need an into() for things like Joiner that do not want to implement an entire Collection interface, just the sink/aggregator part.
On Dec 26, 2012 7:25 AM, "Remi Forax" <forax@univ-mlv.fr> wrote:
On 12/26/2012 04:08 PM, Doug Lea wrote:
On 12/25/12 18:43, Remi Forax wrote:
On 12/25/2012 12:25 AM, Joe Bowbeer wrote:
I was going to say something about into() here but the topic has morphed to
sequential()?
yes, true.
I agree with Brian that into is not as great as it can be but I think the
problem is the interface Destination that into uses.
Maybe we are focusing on different problems, but to me the main
one is a spec/expectations clash: For user-friendliness, we want
relevant properties of sources to be preserved in destinations.
But for generality, we want anything to be put into anything.
This shows up mainly in orderedness, but you can imagine users
"expecting" any other property as well (like sortedness wrt a
comparator). I think this is a no-win situation.
that's why we need two different stream ops,
toList/toSet should conserve the property of the source i.e. create the 'right' Set or List implementation depending on the source property and into that uses the destination property.
The second problem is what is the interface of a stream which is split to be computed in parallel in order to be gathered without using an intermediary data structure as now. For toList/toSet, because the pipeline implementation control the Set/List implementation, so there is no need of such interface, for into(), the question is is with interface pull it's own weight or not ?
\-Doug
R�mi