Design for collections upgrades

[Howard Lovatt]

I agree with all Colin has said below re. using Iterable as the stream
and not having an eager version at all and would suggest:

convert, filter, and fold

as the method names to be consistent with the MethodHandle API where
you can convert, filter, and fold argument lists. It is good to be
consistent with other APIs and also map is used for a HashMap already.

 -- Howard.

On 9 March 2011 09:55, Colin Decker <cgdecker at gmail.com> wrote:
> If there isn't an eager API, the streaming API won't look eager. I can
> appreciate not wanting to confuse people who expect filter() to be eager
> because they're used to copying filtered values into a new collection,
> but that's often not the best thing to do, as has already been pointed out.
> Users have been doing that for everything because there hasn't been any
> other way provided.
>
> I think that filter, map, etc. should be extension methods on Iterable.
> Barring that, the Stream interface or whatever it's called should be
> Iterable. Users can't confuse the results of map and filter with eager
> Collection copies if those results aren't of the right type.
>
> As I see it, all you gain from an eager API is the ability to create a new
> Collection (of a type you have no control over) without calling a copy
> method, plus the ability to shoot yourself in the foot over and over with
> unnecessary chaining of eager calls.
>
> --
> Colin
>
>
> On Tue, Mar 8, 2011 at 4:44 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>>  > I don't feel strongly that we must have an eager
>> > API, but I do feel like we can't have a streaming API that looks like
>> > an eager one.
>>
>> I would agree with this position.  There are pluses and minuses for the
>> eager version, but we can't make the default API either lazy or parallel
>> - you have to ask for that, and it should be reflected in the (static)
>> type system.
>>
>>
>
>



-- 
  -- Howard.