Design for collections upgrades

[Peter Levart]

On 03/10/11, Rémi Forax wrote:
>   Le 10/03/2011 13:19, Peter Levart a écrit :
> > On 03/10/11, Zdeněk Troníček wrote:
> >> >  To me it seems logical that filter() returns the same collection as was
> >> >  the original collection.
> > But that is rarely what you want by default. The eager result you get from filter() is usualy just an intermediate representation of some data. Think of this, for example:
> >
> > ConcurrentMap cMap = ...;
> >
> > Set someKeys = cMap.keys().filter(...);
> >
> >
> > Would you usually want someKeys to be backed by a separate instance of ConcurrentHashMap?
> >
> > Peter
> 
> Peter, I have some problem to understand what is your position.
> Does  cMap.keys().filter(...) return a set or an iterable ?

Since Brian's preposition was that Collection and subtypes should by default implement eager operations and that subtypes can specify covariant overloads, the type of Set.filter() method should be as specific as possible for the most of usecases. For operation filter on a Set I would say it could return a Set (implemented as HashSet) but maybe just a Collection (implemented as an  ArrayList - that's a matter of what is more useable in majority of usecases). To differentiate it with another method, Set.map should return just a Collection (implemented as an ArrayList). If one want's to dump it into a Set (which may loose duplicates and/or order) one can do so explicitly via a Collection.mapTo(Mapper, Collection) method.

Zdenek's preposition that filter() should return the same implementation type of Collection as original Collection is not doable (think of annonymous inner implementations that have no standard constructors and/or reference outer instances of whatever objects).

Peter

> 
> Rémi
> 
> 
>