commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <ggreg...@seagullsw.com>
Subject RE: [lang] CharUtils.isAscii methods and CharSet, two issues
Date Fri, 12 Mar 2004 00:51:46 GMT
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:scolebourne@btopenworld.com]
> 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" <ggregory@seagullsw.com>
> 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:matth@apache.org]
> > 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: 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
> 



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