Design for collections upgrades

[Brian Goetz]

> I suggest that in-place operations, if included, should be named something like
>
> void Collection.retainAll(Predicate<E>  predicate);
> void Collection.removeAll(Predicate<E>  predicate);

Which, conveniently, coincides exactly with our intent.  Map and reduce 
do not make sense as in-place operations, so really the whole in-place 
thing is about filtering, for which we already have sensible names 
(retainAll/removeAll) that are just crying out for lambda versions.

The bigger issues seem to be:
  - Explicit Stream abstraction vs adapting Iterable / Iterator
  - Whether streams should be reusable (Iterable) or not (Iterator)
  - Whether eager operations are desirable or needed at all
  - Whether an explicit toStream method is needed, or whether it is 
acceptable to add new lazy operations to collections (interacts with 
above question about eagerness)

> Finally, I should point out to the language designers out there that
> these APIs can be structured as a monad, not because we want
> programmers to think of them as such but because it provides great
> flexibility in clients wanting to port or reuse code from one
> computational domain to another.  Some expert familiar with such
> techniques should take a more firm role influencing the shape of these
> APIs.  I don't know who is on the expert group so I can't recommend
> anyone in particular.

The conclusion in this last sentence doesn't make sense.  You can 
certainly recommend someone; if by some chance that person happens to be 
on the EG already, then your recommendation degenerates into a mere note 
of approval.