I know your example is a simple case, but, aren't these equivalent?
StringUtils.isNotEmpty(foo)
foo!=null && !"".equals(foo)
Is there some consideration that a method such as "isNotEmpty" is actually a premature over-optimization?
Of course, methods like these are very beneficial when you have languages that restrict or only implement a subset of Java's syntax or capability (such as EL or Velocity etc). But I do agree that we should watch out for small utility methods such as this that could be expressed in about the same amount of local code. We should definitely avoid coupling just to reuse such a method.
-Mark
Stephen Colebourne wrote:
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.
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]
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
