Into

[Howard Lovatt]

In my stream library I made Stream a List. The List methods provided an immutable view into the stream and caused an eager evaluation. This was sufficient for all my needs and is very simple. I found in practice that I didn't do a lot of conversion from stream to array/collection. Once I was in stream, I tended to stay there. 

Have a good Christmas break,

 -- Howard. 

Sent from my iPad

On 23/12/2012, at 9:24 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 12/22/2012 09:21 PM, Doug Lea wrote:
>> 
>> I'm happy to see "into" go. But I'm not all the way sold on whether
>> the best way is via more abstraction (Reducers, Tabulators, etc)
>> versus less. Here's the "less" version.
>> I don't want to argue too hard for taking this approach,
>> but figure that is worth describing:
>> 
>> For mutative additions to collections/maps, why not
>> just let people use either forEach(...add...)  or
>> parallel-forEach(...add..), depending on
>> whether the destination is concurrent and the source
>> amenable to parallelism, and/or whether, in the case of
>> Maps, they want put vs putIfAbsent vs merge. The idioms
>> are easy, and clearly reflect mutative intent. (*)
> 
> Your asking people to take car about the concurrency in their code instead of letting the pipeline taking care of that.
> While it should be possible, that's why there is a forEach, it should not be the default idiom because people will write
>  ArrayList<String> list = new ArrayList<>();
>  list.parallel().filter(...).forEach(list::add);
> We should prefer a slow into() to a fast forEach() that only works if your name is Doug or Brian.
> 
>> 
>> For more functional/fluent/streamy usages, you'd like
>> to enforce that any into-ish method creates a fresh instance
>> and that construction cannot interfere with anything else.
>> So why not treat these as factories in existing catgories:
>>  toCollection(), toList(), toRandomAccessList()
>>  toSet(), toNavigableSet();
>> plus grouping versions
>>  toMap(keyfn, ...), toNavigableMap(keyFn, ...);
>> (with merge- and multi- variants.)
>> 
>> Here the streams implementation gets to pick the
>> underlying concrete class. This may entail sensing
>> parallelism but only in the case of toList is
>> constrained by orderedness.
>> The streams implementation could pick the best applicable
>> options and improve them or pick others over time.
>> (For example, initially,, all of toCollection(), toList(),
>> and toRandomAccessList() could pick ArrayList.)
>> The implementation can also take advantage of the fact
>> that some collections (especially ArrayList) support fast
>> parallel insertion upon creation but not once published.
> 
> you can't use arrayList.addAll(arrayList2) ?
> 
>> 
>> People who don't like the choices of concrete classes
>> can instead use the first option of creating some concrete
>> collections and  populating them.
>> 
>> Summary: Replace into with:
>>  * manual forEach-based idioms for mutative stuff
>>  * opaque factory-based methods for fluent/function stuff
>> And triage out for now any other non-collections-based into targets
> 
> on things that can be done is to write into that way:
>  into(Supplier<? extends T> supplier)
> and used that way:
>  stream.into(ArrayList::new)
> 
> The implementation of the pipeline can check if the Supplier is a constructor reference to a well known collections of the JDK and optimize.
> But in that case, users can not use Collections.newSetFromMap.
> 
>> 
>> (*) footnote: There are now a few more options for
>> parallel insertions into concurrent collections.
>> A while ago I added a "newKeySet" factory
>> method to JDK8/V8 version of CHM, so
>> there is now a JDK Concurrent Set implementation
>> that people can use. Someday similarly for skip lists,
>> so there will be a concurrent sorted/navigable set.
>> High-performance concurrent Lists are unlikely any
>> time soon, although ReadMostlyVector is better
>> than nothing. (I'm still not sure if it should move
>> from jsr166e.extra into JDK...).
>> 
>> -Doug
> 
> Rémi
>