Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <00a701c407d1$eeddf760$4b7c8051@oemcomputer>
From: "Stephen Colebourne" <scolebourne@btopenworld.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
References: <D1639D06CFBD014F87F3978DA7038B934512AC@ns1017.SSSI.seagull.nl>
Subject: Re: [lang] CharUtils.isAscii methods and CharSet, two issues
Date: Fri, 12 Mar 2004 01:32:50 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

The particular example I have in mind is where code like this:

if (str == null || str.length() == 0) {
  return null;
}

has been replaced by:
if (StringUtils.isEmpty(str)) {
  return null;
}

In our normal day jobs this kind of change is a simple way to improve re-use
and readability. However within [lang] it greatly complicates matters wrt
cut+paste, and simply examining the code.

([lang] exists in a world where our users may well choose to press F3 to
look at the code to see if they can replace their code with ours. By adding
another method call we make this visual inspection harder and possibly the
user doesn't use the method.)

This is all counter-intuitive, counter-OO, counter-everything we would
normally do. But I contend that its a key part of [lang].

BTW: Its not necessarily about size/diskspace/download but necessary
dependencies. Basically we can't force everyone to install [lang] in the
same way as everyone is forced to get the JDK. So we need to allow
alternative use strategies when people want tjust some of our code. Cut and
Paste a method is one. Cut and Paste a class is another. We should support
both.

Stephen


----- Original Message -----
From: "Gary Gregory" <ggregory@seagullsw.com>
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


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org