You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Matt Benson <gu...@yahoo.com> on 2008/04/02 23:18:10 UTC
[collections] 4.0 plan and [functor]
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? ;)
-Matt
____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.
http://tc.deals.yahoo.com/tc/blockbuster/text5.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collections] 4.0 plan and [functor]
Posted by Stephen Kestle <st...@orionhealth.com>.
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 <ma...@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
Re: [collections] 4.0 plan and [functor]
Posted by Matt Benson <gu...@yahoo.com>.
--- Stephen Colebourne <sc...@btopenworld.com>
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.
:) I don't really see us doing that to [functor]. My
take is that for each functor interface in
[collections], there is a matching interface in
[functor]. It would therefore seem that a simple
guide "[collections] A -> [functor] B" would suffice.
If we can't all agree on that point, however, I won't
press it.
-Matt
>
> 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
>
>
____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.
http://tc.deals.yahoo.com/tc/blockbuster/text5.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collections] 4.0 plan and [functor]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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