Into (original) (raw)

Joe Bowbeer joe.bowbeer at gmail.com
Wed Dec 26 10:00:07 PST 2012

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 at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20121226/aa6361cb/attachment.html

More information about the lambda-libs-spec-experts mailing list