> -----Original Message----- > From: Stephen Colebourne [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 03, 2004 2:08 PM > To: Jakarta Commons Developers List > Subject: Re: [general][lang] How much to focus on minimising > dependencies > > > The phrase 'cut and pasted' is liable to immediate negative reaction. Try > the phrase 'should be coupled'. > > The argument I put forward is that we should not couple two > classes together > unecessarily just as we should not couple two jar files together. Every > connection made has implications. The positive side effect of reduced > coupling is ease of copy elsewhere. > > The particular case, Validate, struck me as a class that has no need to be > coupled to any other. However others have argued that it should to save on > maintainance or code duplication. I argue that these are poor reasons to > introduce the coupling.
I would argue the opposite - that these are crucial reasons to introduce coupling. When code lives in one place and is shared, every client gets the benefit of the developer base for that code. As a developer, I don't have to keep track of classes, or other code, that I've copied for convenience, so that I can pick up any bug fixes - I just get those fixes automatically. -- Martin Cooper > What has not been argued is the case for the coupling > _based_on_what_the_methods_do_. Validate.isNotEmpty(String) > validates that a > string is not empty. StringUtils.isNotEmpty() tests whether a > string is not > empty. There is actually a legitimate case for coupling here if the aim is > to define validate as being a wrapper around StringUtils adding error > message functionality. (Note I only realised this last night ;-) > > As a counter-example, consider Enum in the enums package which uses > StringUtils to check for non null and non empty string names. Here, Enum > wants non-null and non-empty names. This happens to be the same code as in > StringUtils, but thats a poor reason to couple. > > I know.... its a fine line (and maybe I've failed to explain my point even > now). But where possible, I would like to see each package in [lang] > independent, and ideally also the lowest level utilities (ArrayUtils, > StringUtils, WordUtils,...) > > Stephen > > ----- Original Message ----- > From: "Henri Yandell" <[EMAIL PROTECTED]> > > Changing the subject to kick it more open. > > > > My view is: > > > > (From earlier) > > "As a basic rule, I think it's pretty fair to state that > package hierarchy > > should be obeyed as far as dependencies goes. This means that > a package's > > classes may not depend on a sibling package, or a child package, but it > > may depend on a super-package or classes within the same package. " > > > > Siblings sometimes have to depend on each other, but it's the > same type of > > dependency as inter-project dependencies. > > > > Allowing for a single class to be copy and pasted is too much though. > > > > > > I'd be interested in hearing counter-arguments to this viewpoint. > > > > Hen > > > > On Wed, 2 Jun 2004, Tim O'Brien wrote: > > > > > > -----Original Message----- > > > > From: Stephen Colebourne [mailto:[EMAIL PROTECTED] > > > > Sent: Tuesday, June 01, 2004 5:24 PM > > > > To: Jakarta Commons Developers List > > > > Subject: Re: [lang] Re: cvs commit: > > > > jakarta-commons/lang/src/java/org/apache/commons/lang Validate.java > > > > > > > > > I'm confused -- why shouldn't a class in [lang] have > > > > dependencies to > > > > > other classes in [lang]? Isn't this taking things too far?? > > > > > > > > Its part of [lang] being broad and shallow. In effect, [lang] > > > > is a loose grouping of APIs in a similar vein. As such it > > > > should be easily broken into many parts. > > > > > > > > ie. a user should be able to come along and take one class (wherever > > > > possible) and paste it into their own CVS/project. > > > > > > > > Think of it as a single class jar file. [lang] just provides > > > > a home for it without needing the additional jar packaging. > > > > > > > > Stephen > > > > > > I can't say I agree with this POV, but I do think that it needs a more > > > formal fleshing out than a Re: thread for a CVS commit. > > > > > > I can see the benefit of reducing dependencies among > different projects, > but > > > I don't see a good rationale for not having Validate use StringUtils > and/or > > > ArrayUtils. I'm not of the opinion that we should increase the effort > of > > > maintaining common components because there are people who cut/paste > code > > > into separate projects. > > > > > > Respectfully, > > > > > > Tim > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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]
