Design for collections upgrades

[Colin Decker]

Set.filter() can return a Set view and List.map() can return a List view. Of
course, Set.map() can't very well return a Set view.

-- 
Colin


On Sun, Mar 13, 2011 at 7:36 AM, Rémi Forax <forax at univ-mlv.fr> wrote:

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