Design for collections upgrades

[Rémi Forax]

Good point.
Some collections has views but this view are also collection of the same 
type.

This is not the case of filter/map, set.filter() can't return a Set.
So the result of filter/map is not a view as we know it.

filter/map can returns an Iterable or a Collection
(or a Stream that inherits from Iterable or Collection,
if we want a clean separation between eager/lazy world).

So for me the question is: should filter/map return
something that is more like an Iterable or more like
a Collection.

There is one advantage to use Collection instead of Iterable,
which is the interoperability with bulk operations (addAll, retainAll, 
containsAll, etc.).

Rémi

On 03/13/2011 12:12 PM, Steven Simpson wrote:
> On 10/03/11 13:57, Rémi Forax wrote:
>>    Yes, we need to provide methods that filter/map directly
>> the content of a collections.
>> But I don't think it's a good idea to name them filter or map.
>>
>> Why not filterAll and mapAll ?
> I'm starting to lose track of this thread, but I recall the following
> points:
>
>      * Lazy operations are desirable, as are eager ones, and in-place ones.
>      * There could be a type or family thereof for lazy collections, e.g.
>        Stream or Iterable.
>      * Collections currently don't have methods for generating new
>        collections, so adding them is a considerable shift.  They do have
>        in-place methods, and new methods like 'filter' share the same
>        tense, suggesting that they should be in-place methods too.
>
> In case it hasn't yet been mentioned, I'd like to add that collections
> also support /views/ in several places, e.g. subList, entrySet, etc.  Do
> we need a lazy type when we can have views?  I haven't pinned it down in
> my mind yet, but I suspect that views are slightly different to streams,
> in that they also allow us to modify the original collection.  Or, to
> put it another way, they differ from mutating methods, in that we can
> choose not to perform any mutation.
>
> When we want to delete a portion of a list, we write:
>
>    list.subList(a, b).clear()
>
> ...because the sublist view allows us to modify the original list.  But
> if we want to extract a sublist, and leave the original untouched, we write:
>
>    new ArrayList(list.subList(a, b))
>
> List.subList could be regarded as lazy, until we apply a mutating method
> to it like clear().  And if we never do that, it stays lazy even while
> we do an eager copy.
>
> Can we do the same with filter (using a noun like "selection" to be
> consistent with subList)?
>
>    list.selection(pred).clear(); // mutating original; removeAll(pred)?
>    new ArrayList(list.selection(pred)); // preserving original
>
> Views, having ordinary collection types, remain Iterable too:
>
>    for (Element elem : list.selection(pred)) { ... }
>
> I suppose my point is that there is already a precedent for (mutable)
> laziness in the collection framework, in the form of views.
>
> Cheers,
>
> Steven
>