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 03:13:33 GMT
I think I'll agree to disagree. But now what? Are you saying that we
should unroll all [lang] API calls within lang to make for easy cut and
pasting? I know that is extreme - and I wrote it tongue in cheek - but
where do you draw the line?

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

If it is so anti-everything, how can we condone it? It disagree that
cut-and-paste should be a design goal. In fact, eating our dog food
provides both the laundry list of standard OO and API library benefits
*as well as* example usages. 

I think that in the extreme case where lang would not call itself, we
would have the additional burden of providing examples for every API. We
also would have to answer to folks who would wonder WHY we do not use
our own APIs. My guess is that to answer this with "because then you can
cut and paste better" would leave many scratching their propeller-heads
(me included).

The example you give illustrates a great strength of lang, though, the
centralization of the "is empty" policy.

Gary

> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Thursday, March 11, 2004 17:33
> To: Jakarta Commons Developers List
> Subject: Re: [lang] CharUtils.isAscii methods and CharSet, two issues
> 
> 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
> 



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