commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <si...@ecnetwork.co.nz>
Subject RE: [lang] Re: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang Validate.java
Date Wed, 02 Jun 2004 01:12:15 GMT
On Wed, 2004-06-02 at 10:54, Gary Gregory wrote:
> I agree with Michael. 
> 
> When did this become is this a design goal? I am against it. :-(
> 
> It is one thing to say, "I'll cut and paste [lang] code /into/ my own
> project, and yes, I know about duplicating code, not getting bug fixes,
> etc". 
> 
> It is another to say: "Let's inline APIs within [lang] to make it easier
> to cut and paste", and knowingly making lang *harder* to maintain *by
> deisgn*, this is not a good thing from my POV. 
> 
> This turns a project on its head from a "eat your own dog food"-style
> library into a set of macro like templates. 
> 
> We've broached this topic before in the context of cross-project
> dependencies. Each project decides whether to introduce a dependency or
> duplicate code, that's quite fine. But IMO, not within lang.
> 
> ***If you want a cut and paste library, then create it in docs and let
> folks cut and paste from /that/ since they would not use the lang jar in
> the first place!*** Why muck up a jar that the described audience would
> not use?
> 
> Sorry for the flame but this is a 'shake-my-head-in-disbelief' moment
> that I find discouraging. 
> 
> I say: stop the in-lining. Where will it stop, how do you decide which
> ones to in-line or not. Arg....

I disagree. I'm in favour of *thoughtful* and *appropriate* duplication
of code to reduce dependencies.

We've already had a discussion of the appropriate partitioning of the
collections library, and the same debate could be had about any library.
There isn't any fixed rule that says where a dividing line should be
drawn. Different users draw the line in different places.

In the end, the nice thing about open-source is that users of the code
can repartition the libs as they desire. If someone wants an
"all-in-one" commons jar, then they can create one. If someone wants
only a few classes from commons-net, then they can extract them into a
separate lib.

The fact that a particular set of classes is maintained together as one
commons project doesn't mean that *everybody* sees that library as an
indivisible group of classes. I suggest going back and reading the
discussion on collections, where arguments were put forward that
collections should in fact be split into about 5 different libs. I
disagreed with that, but support structuring the code so that a user who
wants only 20% of a particular lib is *able* to extract just the bits
they want.

Reducing the dependencies between components within a lib helps users
create their own customised lib subsets.

Of course there is a price to duplicated code that we are all aware of.
So judgement has to be applied to determine when it is appropriate. And
I think the regular committers on a project are the ones in the best
position to make that call. After all, if a bug *is* discovered in
duplicated code, they will be the ones changing all instances of that
code - and they are aware of that.

Regards,

Simon


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