I checked it out, and it does appear that relaxing the current defaultString(String) signature would do the trick. Does this change need a deprecation cycle or can we just change the signature since existing calls to defaultString should not be affected?
Steven Caswell [EMAIL PROTECTED] a.k.a Mungo Knotwise of Michel Delving "One ring to rule them all, one ring to find them..." > -----Original Message----- > From: Steven Caswell [mailto:steven@;caswell.name] > Sent: Wednesday, October 23, 2002 4:42 PM > To: 'Jakarta Commons Developers List' > Subject: RE: [lang] [patch] StringUtils.defaultString > > > I'm +1 on putting them in StringUtils because I tend to think > of these as "doing something" with strings. In other words, I > typically do something like this when trying to output the > string representation of an object, such as when dealing with > method arguments in a debug log. I struggled with whether > they are more ObjectUtils, but I think actually they make > sense in StringUtils. > > As far as relaxing the current defaultString(String), I seem > to remember having some problem doing that when I wrote my > own version of these. If I get time in the next day or so > I'll try it again. > > And I think I'd be -1 on renaming to defaultIfNull etc. I > don't think the deprecation complication is worth the benefit. > > Steven Caswell > [EMAIL PROTECTED] > a.k.a Mungo Knotwise of Michel Delving > "One ring to rule them all, one ring to find them..." > > > > -----Original Message----- > > From: Henri Yandell [mailto:bayard@;generationjava.com] > > Sent: Tuesday, October 22, 2002 9:00 PM > > To: Jakarta Commons Developers List > > Subject: Re: [lang] [patch] StringUtils.defaultString > > > > > > Managed to get them out. Edited the mailbox by hand and it > > seemed to work. Odd :) > > > > Anyways. Looks like the current defaultString could happily > > handle them by weakening the parameter from a String to an > > Objeect. What do you think? > > > > Hen > > > > On Tue, 22 Oct 2002, Henri Yandell wrote: > > > > > > > > Went to look at em, and pine is not happy with the > > attachments at all. > > > One it refuses to open [something illegal in the encoding] and the > > > other is empty. So not sure what happened to me there. > > > > > > Could you summarise the methods inline? > > > > > > I assume: > > > > > > public String defaultString(Object o) { > > > return defaultString(o, ""); > > > } > > > > > > public String defaultString(Object o, String s) { > > > return (o == null)? s : o.toString(); > > > } > > > > > > ???? > > > > > > As to where it lives. Am unsure. Is a Utils based on what > > goes in or > > > what goes out.. Should this really go in a ConvertUtils > > [it'd get lost > > > I think]. > > > > > > I would think that the current > > > StringUtils.defaultString(String,String) > > > should simply be changed to be more generic. As we've > > released, moving it > > > to ObjectUtils seems unneeded and bad, there's > > justification for it to go > > > either way. > > > > > > Renaming defaultString to defaultIfNull, or defaultStringIfNull or > > > changing ObjectUtils.defaultIfNull to defaultObject would > > be nice in > > > hindsight, but I is it worth throwing deprecations > around? Probably > > > not :) > > > > > > Of course, I could be making assumptions on what's in the patch. > > > > > > Hen > > > > > > On Tue, 22 Oct 2002, Stephen Colebourne wrote: > > > > > > > I think these methods fit better with ObjectUtils. What > > d'ya think? > > > > > > > > Stephen > > > > > > > > From: "Henri Yandell" <[EMAIL PROTECTED]> > > > > > Will apply today at some point [writes it down on the > > whiteboard, > > > > > where of course nothing ever gets deleted] > > > > > > > > > > Hen > > > > > > > > > > On Mon, 21 Oct 2002, Fredrik Westermarck wrote: > > > > > > > > > > > Hi! > > > > > > > > > > > > Here is a patch that adds the defaultString(Object) and > > > > defaultString(Object, > > > > > > String) to StringUtils. I've also attached a patch > > with the test > > > > > > cases > > > > for the > > > > > > new methods. > > > > > > > > > > > > > > > -- > > > > > To unsubscribe, e-mail: > > > > <mailto:commons-dev-unsubscribe@;jakarta.apache.org> > > > > > For additional commands, e-mail: > > > > <mailto:commons-dev-help@;jakarta.apache.org> > > > > > > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > <mailto:commons-dev-> [EMAIL PROTECTED]> > > > > For > > additional commands, e-mail: > > > > <mailto:commons-dev-help@;jakarta.apache.org> > > > > > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:commons-dev-> [EMAIL PROTECTED]> > > > For > > additional commands, > > e-mail: > > > <mailto:commons-dev-help@;jakarta.apache.org> > > > > > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:commons-dev-> [EMAIL PROTECTED]> > > For > > additional commands, > > e-mail: <mailto:commons-dev-help@;jakarta.apache.org> > > > > > > > > -- > To unsubscribe, e-mail: > <mailto:commons-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:commons-dev-help@;jakarta.apache.org> > > -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
