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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
------------------------------------------------------------------------
* <http://www.orionhealth.com>*
*Stephen Kestle Software Engineer*
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
