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]
