I thought part of the aim of the Utils was to avoid having top level classes, even if they are package scoped.
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. Stephen (I've just changed ISP, so I may break the thread with this email, sorry) ----- Original Message ----- From: "Michael A. Smith" <[EMAIL PROTECTED]> > On Fri, 14 Jun 2002, Jack, Paul wrote: > > > > we could even make them public classes and allow users to > > > extend them on > > > their own (using the XXXUtils.whatever methods as convenience methods) > > > > Well, yes...but we'd be adding like 30 classes to the public API. > > Maybe have a separate package for decorators? > > seems reasonable... but I think we should take small steps in terms of > the public API. Make the decorators available via the Utils, then if > users really want them, move the classes out from package private status > to public in a separate package... > > michael > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
