You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2004/06/03 06:46:47 UTC
[general] How much to focus on minimising dependencies Was: [lang]
Re: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang
Validate.java
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
Re: [general] How much to focus on minimising dependencies Was:
[lang] Re: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang
Validate.java
Posted by Serge Knystautas <se...@lokitech.com>.
Henri Yandell wrote:
> 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 agree with the above part.
I don't see how that simply making this statement is inadequate, nor how
the suggested package dependency rules better codify those goals. It's
late for me though, so maybe I'm missing the point.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general][lang] How much to focus on minimising dependencies
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
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" <ba...@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
RE: [general][lang] How much to focus on minimising dependencies
Posted by Martin Cooper <ma...@apache.org>.
> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> 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" <ba...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [general][lang] How much to focus on minimising dependencies
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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" <ba...@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