commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kenneth Xu" <kenne...@gmail.com>
Subject RE: [jira] Commented: (COLLECTIONS-110) [collections] Support parametized classes with commons.collections.
Date Wed, 21 Jun 2006 11:58:06 GMT

>From a developer point of view, I certainly support the radical approach
especially after I realized keeping backward compatibility is so damn hard.
I have blogged something on this topic.

http://kennethxu.blogspot.com/2006/06/is-definition-of-map-interface-broken.
html

But from a common library user perspective, backward compatibility is
essential as we have so much code written depending on Commons-Collections.
We wish the Bag is the same Bag so that we can pass the reference between
legacy codes and newly developed type-safe codes. After all,
interoperability with legacy code is one of major selling points of
Generics.

So is there a compromise act?

> I would add:
> - base package: All interfaces + Utils (CollectionUtils, MapUtils etc)

I too think it make sense to have base package include all interfaces (about
20-30 as of today). And the compromise might be that as long as we keep
those interfaces backward compatible, majority of legacy code can happily
interoperate with new type-safe code. I checked near all the code in my
domain. None of them refers to class of commons-collections in its public
interface, while interfaces like Bag, Transformer and etc are used.

Interfaces like MulitMap cannot be generified and still maintain backward
compatible given the Map definition in JDK 5. We can deprecate it and give
the Generics version a new name like One2ManyMap.

Kenneth Xu


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message