Design for collections upgrades

[Steven Simpson]

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

--