commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [general][lang] How much to focus on minimising dependencies
Date Fri, 04 Jun 2004 13:07:11 GMT
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" <bayard@generationjava.com>
> 
>>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:scolebourne@btopenworld.com]
>>>>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: 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
> 

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu

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