On Sat, 15 Jun 2002, Stephen Colebourne wrote: > I thought part of the aim of the Utils was to avoid having top level > classes, even if they are package scoped.
yeah, in a way. They coule also be looked at as convenience methods where you only need to import one class name to get all of the functionality rather than importing each that you need. > The problem as I see it is that someone new to the package will come along > and see maybe 60+ classes in the collections package. However, over half > could be package scoped with no way to tell. (I reckon most people would > scan the class names first, either as java files or javadoc.) By defining > them as static nested classes (package scoped) we avoid the visibility > issue. Joshua Bloch's book described it as reducing the 'conceptual size' of > the API. I wouldn't want all 60+ classes in the collections package, even when package private. To start, I believe adding them as inner classes or non-public outer classes in the xUtils.java file would be a good starting point (hence they aren't exposed in javadoc or as .java files). Then, if a compelling need arises, we can make them public classes, but in a separate package (e.g. "org.apache.commons.collections.decorators"). regards, michael -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
