On Mon, 23 Apr 2001, Waldhoff, Rodney wrote:
> > Will there be efficiency differences large enough to warrant two different
> > implementations
>
> Taking a quick look at the current implementation, it seems that all the
> methods that are being used are simply methods of Collection, so I don't see
> any issues there. I guess we'll have to settle on some type of Collection
> to return though. (Set?).
>
> I guess I'll go ahead and introduce CollectionUtil, taking Collection
> arguments, and I'll add disjunction() as alias for a deprecated sum().
>
> I think we probably still want to think about the semantics of element
> cardinality a bit--e.g., currently if list A has 1 copies of "foo", and list
> B has 3 copies of "foo", ListUtils.itersection(A,B) will contain 3 copies,
> which doesn't seem quite right to me. At that time "there be efficiency
> differences large enough to warrant two different implementations". Let me
> take a stab at it and I'll see what everyone thinks.
>
>
Seems like a reasonable approach.
If we find cases where we can improve performance for particular types of
collections, we can always overload the method names later, eg:
public static Collection intersection(Collection coll1, Collection coll2);
public static List intersection(List list1, List list2);
...
and let the compiler pick the right one for you.
Craig
