commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang] Package structure [was UUID Reuse proposal]
Date Tue, 19 Aug 2003 00:28:56 GMT
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" <mhawthorne@alumni.pitt.edu>
> 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:phil@steitz.com]
> >>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: commons-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


Mime
View raw message