Hello, I have to disagree on the cut-and-paste notion. Writing library gut code with the purpose of it being cut-and-paste-able seems... well I can't even think of a word for it! ;-)
Lang is a library, I usually cut and past call site examples, not library guts. I can't even begin to imagine the maintenance nightmare of keeping up with bug fixes. I could consider copying a whole method or a whole class... but bits and pieces? Not for me. As far as pulling in a "whole" library, to me this has never been an issue. The 1.4 rt.jar is 26 megabytes, lang is 170k, a CD holds 700MB, disk space is cheap and a JVM only loads the classes it needs. For applets it is a different story, small is good, but then, reusing code would *reduce* the footprint, making [lang] more attractive. When I fix a bug, I want to fix it in one place and have all of the call sites benefit. As soon as I see the same thing done in two different places in two different ways, especially for low-level doo-dads in lang, things feel slightly off to me. Cheers, Gary > -----Original Message----- > From: Stephen Colebourne [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 11, 2004 15:51 > To: Jakarta Commons Developers List > Subject: Re: [lang] CharUtils.isAscii methods and CharSet, two issues > > While I'm not opposed to seeing some performance results, I would still > argue to keep the existing methods (written as is). > > [lang] has a task of writing boring code. Code that should be in the JDK. > The static method pattern has been adopted as the way around not being > able > to add methods to the JDK. > > There is a second task that [lang] had which has been lost over time by > various changes that people have made. That is that [lang] should be a > repository of code that people can cut and paste to their own code. > > This may scare some, but it is actually quite sensible. Not eveyone wants > to > pull in the entire [lang] library when they only want a couple of > functions. > (I fully understand there are many ramifications of cut and paste, but it > was IMHO part of the intent of [lang]). > > However, what has happened is that many [lang] methods have been > 'optimised'/changed to reuse other methods, notably for > StringUtils.isEmpty > and ArrayUtils checks. These make the cut and paste approach much harder, > and possibly slow up the code, for a small amount of reuse. > > So, what I am arguing for is, where possible, each method in a XxxUtils > method to be standalone, and certainly not to have needless dependencies. > > Stephen > > > ----- Original Message ----- > From: "Gary Gregory" <[EMAIL PROTECTED]> > I'll write up a little test over the weekend if not sooner. > > > There are lots of good changes that don't add any functional > improvement > > at the machine level, but a more OO solution may very well improve > > things at the maintenance and class heirarchy level. > > This is what I am striving for. > > Gary > > > -----Original Message----- > > From: matthew.hawthorne [mailto:[EMAIL PROTECTED] > > Sent: Thursday, March 11, 2004 13:56 > > To: Jakarta Commons Developers List > > Subject: Re: [lang] CharUtils.isAscii methods and CharSet, two issues > > > > Todd V. Jonker wrote: > > > As is stands, isAsciiAlphaUpper follows > > > DoTheSimplestThingThatCouldPossiblyWork but (perhaps) breaks > > > OnceAndOnlyOnce. > > > > > > Still, I think the existing code is better. Such things tend to be > > > called inside tight inner loops, and as such every bytecode counts. > > Your > > > suggested rewrite adds no functional improvement while increasing > the > > > execution time manyfold. I strongly suggest leaving it as-is. > > > > > > I think that running some performance tests would provide the best > > insight into possible effects on execution time. Gary, maybe you > could > > write a small test to see if this change truly would cause a > performance > > problem? > > > > There are lots of good changes that don't add any functional > improvement > > at the machine level, but a more OO solution may very well improve > > things at the maintenance and class heirarchy level. > > > > > > --------------------------------------------------------------------- > > 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] > > > --------------------------------------------------------------------- > 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]
