commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Smith <st...@stephen-smith.co.uk>
Subject Re: [collections] Generics & the collection subpackage
Date Sat, 04 Nov 2006 00:11:02 GMT
+1

Better to break compatibility upfront as part of an explicit design 
decision, than to see it slowly wither away.
--
Stephen Smith, MEng (Wales).
http://www.stephen-smith.co.uk/

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: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> 


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