commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject Re: [id] util package
Date Mon, 31 May 2004 14:20:43 GMT
Stephen Colebourne wrote:
> 
>>Given the number of [codec] classes involved, I would rather keep the
>>dependency.
> 
> 
> The question is whether you actually want these classes, or just part of the
> code within. The exceptions certainly shouldn't be needed, nor the
> Decoder/Encoder superclasses. And none of them should be part of the public
> API of [id].
> 
> The issue here is whether, I as a user, can just come along and pick up the
> library and not need to think about dependencies etc. If I just want an
> incrementing number id, then why should I take codec? (I know you wouldn't
> need to but that is basically too confusing to try to explain.)
> 
> So two solutions:
> 1) Create one package scoped utils class in [id] with just the relevant
> methods on it.

Do you think that this is a good strategy in general?  What happens when 
bugs are found or efficiency is improved in the cut-and-pasted methods 
from the source component?  Do you cut-paste-modify test cases as well?
So far, it seems that we are collectively OK with this when the amount of 
copied code is "small" and its state is "stable."  Do I have this right?

What made me think we should keep the dependency in the present case is 
the number of classes and the fact that some of what is needed is in CVS HEAD.
> 
> 2) Produce two multiple files - id-all, id-uuid and id-simple, the first two
> having a codec dependency.
> 
> I'd suggest the first solution is preferable.
> 
> 
> One way to try and picure this is to classify [id] in the bigger scheme of
> things. [lang], [collections], [io] and [codec] are all low level APIs - no
> dependencies. Hopefully [beanutils] will join the group soon. Then there is
> a next level up, [betwixt], [digester], [jxpath], [validator] which do have
> dependencies (also [oro], [regexp], [bcel]...). This is quite a big
> difference in a library - and maybe if commons keeps growing, then these
> could become two projects/mailing lists - eg. commons-base and commons-app.
> Which group does [id] fit with? I'd suggest it should be the first.

I understand what you mean here; but making "low-level" synonymous with 
"no dependencies" may force us to split some things apart.  The guid 
portion of [id], for example, could be viewed as "low level" (close to 
JDK) but has a natural dependency on [codec].  I guess this amounts to 
your option 2) above.

Out of curiousity, where would you put [math] in the scheme above? I 
suppose there could be a "math-base" with no dependencies and a "math-app" 
with some dependencies?

For [math] 1.0, I think we can squeeze out all but optional dependencies; 
but I would like to get the BeanUtils-dependent stuff back in at some 
point.  The dependency that is giving me the most trouble is Frequency (a 
pretty "low-level" API) depending naturally on TreeBag from [collections]. 
  I don't see Frequency as any less "low-level" than, e.g., Mean.

I suppose that one solution would be to move Frequency into [collections]. 
  I know that sounds ridiculous. The point is that if we want to factor 
components to minimize both dependencies and code duplication, and to keep 
"low-level APIs" dependency-free, we might end up with a different set of 
component boundaries than what we have now.

Phil
> 
> Stephen
> 
> 
> 
> ---------------------------------------------------------------------
> 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