commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: [collections] Generics & the collection subpackage
Date Sat, 28 Oct 2006 06:06:38 GMT
On 10/27/06, Stephen Colebourne <scolebourne@btopenworld.com> wrote:
> First analysis of the collection subpackage of [collections] for the
> generics branch.
>
> - BoundedCollection should be deleted/renamed to Bounded
> new Bounded interface would not implement Collection, allowing it to be
> implemented by Maps as well as Collections
>
> - UnmodifiableBoundedCollection should be deleted
> Just use the isFull/maxSize methods on CollectionUtils or similar
>
> - AbstractSerializedCollectionDecorator should be deleted
> Serialization can now be rolled up into the base decorator
> This simplifies a lot of code
> It wasn't done originally due to back-compat
>
> - TransformedCollection will need some thinking about to generify, as a
> transformer can change object types
>
> - Consider adding a Decorator interface
> This would provide a single method decorated() that obtains the
> collection that has been decorated.
> Whilst useful, this is also potentially dangerous exposure of state.
>
> - Consider adding a Container interface
> This would be a base super interface for Collection and Map (but
> obviously we can't hack the JDK.
>
> - Consider whether UnmodifiableCollection should be deleted as it
> duplicates the JDK.

Should we delete the EMPTY_MAP, EMPTY_COLLECTION, EMPTY_SET bits?
They're in the JDK now.

Maybe we should create a JIRA issue for all the things that should be
deleted as being in the JDK. Store them up there and take care of them
if we decide that we're going to aggressively break backwards compat.

Hen

---------------------------------------------------------------------
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