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]
