Into

[Joe Bowbeer]

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