Rodney Waldhoff wrote:
On Fri, 13 Dec 2002, Emmanuel Bourg wrote:

Clearly the intention behind deprecating a method or class is to remove
it.

(i) deprecating (with the intention of removing) released classes
The intention is to no longer use it. It *may* be removed at a later date, but that may never happen. That would be debated in another discussion i think.

(ii) adding a new compile-time and run-time dependency to a released component
That's not like re-releasing a component, Commons Collections 2.1 is out and works well as is, with no dependency. On releasing 2.2 it will be easy in the release notes to warn developpers about the new dependency, it already happened for other components.

(iii) changing the originally proposed scope of lang
"(1) Scope of the Package
This proposal is to create a package of Java utility classes for the
classes that are in java.lang's hierarchy, or are considered to be so
standard as to justify existence in java.lang. The Lang Package
also applies to primitives and arrays."

I admit the scope is very general but Stephen's suggestion still fits the originally proposed scope : functors are low level general elements that would be used in a wide range of applications, it's sensible to place them in [lang].

(iv) reducing the scope of the released collections)
"(1) Scope of the Package
The package will create and maintain a set of collections and
related classes designed to be compatible with the Java Collections
Framework, and to be distributed under the ASF license."

That doesn't reduce anything from the collections' scope. It's not like removing java.util.List support in [collections] to put it in a new [lists] component.


I hope it will help to clear your doubts :)

Emmanuel


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to