If only I had more than +1 vote!
Stephen Colebourne wrote:
There has been reltively little feedback on these backwards
incompatible changes. Do I assume (by lazy consensus) that
[collections-generics] will be seriously backwards incompatible? Can I
commit changes? Are we agreed on the strategy "produce the best API",
rather than "produce a compatible API".
Stephen
Stephen Colebourne 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.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
