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-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
