There are two forms of linking here - inter-method and inter-class. What I mean by this is that I would prefer for the main Utils classes to be independent of other Utils classes if possible. (I haven't checked on the viability of this)
Its probably too late for this concept now, and I'm not about to head in and search [lang] for changes. So probably most of what has been done will remain. But I believe it limits the reuse of the component. Stephen ----- Original Message ----- From: "Gary Gregory" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> > 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] > > > --------------------------------------------------------------------- > 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]
