Matthew pretty much describes the thinking in [lang] and what I do. I dislike large packages, especially in OSS.
One way to learn a library is to browse the packages. By keeping related things together you can learn the API one package at a time, or dismiss a package if it is unimportant to you. The danger is actually elsewhere for [lang], and that is one of including too much. We have already kicked out the functor package to the much better planned [functor]. Also math has been kicked out to [math], with just very basic lang level functions remaining. The reflect subpackage really ought to go the same way (and I will probably propose this sometime soon). Stephen ----- Original Message ----- From: "__matthewHawthorne" <[EMAIL PROTECTED]> > I think that the creation of multiple small packages is more of a > practical exercise than a theoretical one. > > For example, if [lang] contained 500 classes which all, in some way or > another, were "extensions" to java.lang... it may make sense from a > certain standpoint to throw them all in the root package. > > However, in practice, it seems easier to break up the classes into > smaller sets, where it can be determined that set A depends on set B, > one group of developers is working on set C while another works on set > D, set A needs a certain type of test data while set C needs another, etc. > > I don't see packages as namespaces so much as functional groups; they > help to maintain order of depencencies, tests, developers, etc. > > I also find some APIs with large packages difficult to browse (everyone > seems to have a *.util package with millions of classes in it), but that > may just be a personal preference. > > Any thoughts? > > > > > Gary Gregory wrote: > > >On the general topic of Java packaging and not to consider until the far 3.0 > >future ;-) > > > >I think that we have a bit of package inflation already. From my POV, > >commons-lang extends java.lang and all of its stuff should just go in > >o.a.c.lang. But that's just me. I think that when you consider that packages > >are namespaces, I do not think that we need to keep all of what now makes up > >lang in separate namespaces. > > > >Just as an example, I find the use of a lang.builder package an odd choice > >rather than putting it all in lang. What do all the builder classes have in > >common? The only thing I can think of is that they provide the same kind of > >implementations to provide their services. Hardly worth a separate > >namespace, IMHO again. > > > >Gary > > > > > > > >>-----Original Message----- > >>From: Phil Steitz [mailto:[EMAIL PROTECTED] > >>Sent: Monday, August 18, 2003 00:06 > >>To: Jakarta Commons Developers List > >>Subject: Re: UUID Reuse proposal > >> > >>Tim Reilly wrote: > >> > >> > >>>Thanks for the positive response to adapting a UUID class in commons > >>> > >>> > >>lang. > >> > >> > >>>[The Axis list has responded with favoring option 2 which is basically > >>> > >>> > >>to > >> > >> > >>>not make changes at this time, but has no problem with use of the UUID > >>> > >>> > >>code > >> > >> > >>>from Axis in the commons.] > >>>I'm looking for direction on next steps - I believe after answering the > >>>following questions; I would create an enhancement in bugzilla and > >>> > >>> > >>attach > >> > >> > >>>patches or sources? > >>> > >>> > >>Yes. I would start by patching IdentifierUtils (see below) to add some > >>additional methods, assuming that there are no objections to this > >>approach. > >> > >> > >> > >>>I think at this time there are two questions to resolve: > >>> > >>>~1) Where to place the UUID code. > >>>I personally prefer a package and separate classes as Phil Steitz > >>> > >>> > >>suggests: > >> > >> > >>>" > >>> > >>> > >>> > >>>>I do like the idea of lang providing a home for "IdentifierUtils" > >>>> > >>>> > >>suitably > >> > >> > >>>>named and packaged. There are really multiple types here: > >>>> > >>>>* UUID (pseudo) standard, non-random, non-secure > >>>>* Random, non-secure, not guaranteed unique (e.g. RandomStringUtils) > >>>>* Random, "secure", not guaranteed unique (e.g. Tomcat session IDs) > >>>>* Part random, "secure", guaranteed unique (what Tomcat really needs ;-) > >>>>* Bounded sequential(e.g. Betwixt's io identifiers) > >>>>* Cyclic" > >>>> > >>>> > >>>I believe the alternative is to add the UUID code to the existing > >>>IdentifierUtils.java. > >>> > >>> > >>Sorry, I had forgotten about the existing IdentifierUtils. I would > >>suggest that all of the things above could be added there, at least to > >>start. > >> > >> > >> > >>>(As a user of the library I believe it would be much easier to locate > >>> > >>> > >>and so > >> > >> > >>>more valuable to have in a "suitably named package" of > >>> > >>> > >>IdentifierUtils.) > >> > >> > >>>~2) Which UUID implementation to use: > >>>Tim Anderson suggested using: > >>>http://cvs.sourceforge.net/cgi- > >>> > >>> > >>bin/viewcvs.cgi/tyrex/tyrex/src/main/tyrex/se > >> > >> > >>>rvices/UUID.java?rev=1.6 I think this is a good suggestion. Does anyone > >>> > >>> > >>know > >> > >> > >>>if there are any issues with the license on this. It seems it would be > >>> > >>> > >>okay > >> > >> > >>>as long as this license information were included along with the apache > >>>license in the source. (Would we also need an additional UUID- > >>> > >>> > >>License.txt? > >> > >> > >>>I'm not sure how to interpret item 2 of license) The alternative is to > >>> > >>> > >>use > >> > >> > >>>the Axis UUID and add features such as those in Tyrex's later. If a real > >>>issue exists I could try contacting them so find a suitable solution. > >>> > >>> > >>I don't know about the license, but as I said above, I like the tyrex > >>impl better. In any case, making the implementation threadsafe would be > >>a good idea, as would (IMHO) allowing the node ID to be read from a > >>properties file. I would also be interested in others' opinions on the > >>value of the UUID "standard", especially minus the MAC address. > >> > >>Phil > >> > >> > >> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
