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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
