commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Kestle <stephen.kes...@orionhealth.com>
Subject Re: [collections] 4.0 plan and [functor]
Date Mon, 28 Apr 2008 22:07:26 GMT
 From memory, there are 4 use cases for jar splitting (across 
collections and functor):
1. "Just give me everything"
2. "I don't want all the fancy functor stuff"
3. "I want minimal collection utility support"
4. "I want the collections and maps, but none of the fancy functor guff"

To support all of these, we'd need to split collections and functors 
into interface and util classes only, collection extension jar and full 
jars.

What I reckon we should do is:
* an extraction of the collections functors into functor-basic
* another cut of functor that contains everything
* A full cut of collections
* A new community ant build file that deals with modifying these jars 
into different slices that people want.  If we try to guess what end 
users want, then we're going to get it wrong, and provide lots of 
confusing options for most users.

BTW, in terms of the original proposition of deprecating what was in 
collections - you need to have the better replacement available.  This 
would mean the extraction of functors, and at least "interface 
collections.Predicate extends functors.Predicate" and all the other 
classes so that working plug in replacements are available.  I am 
definitely for this as a means for migration, and preparation of 
packaging (functors will need to be included in new collections.zip 
distributions).

Cheers

Stephen

Stephen Colebourne wrote:
> Matt Benson wrote:
>> We've talked about releasing a Collections 4.0 with
>> deprecations removed.    With all the recent interest in [functor], 
>> it seems
>> like it might be time to deprecate functor-related
>> code from [collections] in 3.3 (or 3.4, but more
>> notice is better than less) for removal in 4.0 with
>> [functor] being the suggested replacement.  I was
>> thinking Collections might need to keep the basic
>> interfaces and some sort of compatibility code, but as
>> long as we ensure [functor] contains usable
>> alternatives for everything [collections] has I don't
>> see a problem.  This would be a pretty drastic move,
>> though... who has objections?  ;)
>
> We need to be careful of forcing the users of [collections] to use a 
> much more complicated [functor].
>
> Basically, the original [functor] was an API with a lot more 
> interfaces and complexity. Whilst it was a more complete 'functor' 
> approach, it probably wouldn't suit as a replacement for the functor 
> elements of [collections].
>
> If the intention is to simplify [functor] to the level of the four 
> interfaces of [collections], then splitting out all the functor-style 
> code from [collections] might make sense.
>
> There would still be no need to deprecate though, as [collections-5] 
> would just omit the classes as it is backwards incompatible anyway.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

-- 
------------------------------------------------------------------------
* <http://www.orionhealth.com>*
	
	

*Stephen Kestle Software Engineer*
stephen.kestle@orionhealth.com <mailto:stephen.kestle@orionhealth.com>
P: +64 9 638 0619
M: +64 27 453 7853
F: +64 9 638 0699
S: skestle <callto:skestle>
www.orionhealth.com <http://www.orionhealth.com>


This e-mail and any attachments are intended only for the person to whom 
it is addressed and may contain privileged, proprietary, or other data 
protected from disclosure under applicable law. If you are not the 
addressee or the person responsible for delivering this to the addressee 
you are hereby notified that reading, copying or distributing this 
transmission is prohibited. If you have received this e-mail in error, 
please telephone us immediately and remove all copies of it from your 
system. Thank you for your co-operation.

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


Mime
View raw message