commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Downey <steve.dow...@netfolio.com>
Subject Re: [lang] [patch] StringUtils.defaultString
Date Mon, 28 Oct 2002 04:53:32 GMT
Is it worth breaking binary compatibility versus adding the Object API's?
Perhaps overloading the defaultString with both API's?

On Sunday 27 October 2002 02:31 pm, Henri Yandell wrote:
> Oh. Except people might need to recompile their code that calls
> defaultString. The ant test failed for me as I didn't recompile
> StringUtilsTestCase.
>
> Hen
>
> On Sun, 27 Oct 2002, Henri Yandell wrote:
> > I wouldn't think so, but I'm often accused of having a 'break it now so
> > they notice' attitude :)
> >
> > I can't think of how this would break any normal usage.
> >
> > Will make the change and revert if anyone complains.
> >
> > Hen
> >
> > On Sun, 27 Oct 2002, Steven Caswell wrote:
> > > 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
> > > steven@caswell.name
> > > 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
> > > > steven@caswell.name
> > > > 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" <bayard@generationjava.com>
> > > > > > >
> > > > > > > > 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-> unsubscribe@jakarta.apache.org>
> > > > >
> > > > > > > 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>
> > > > >
> > > > > --
> > > > > 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-> unsubscribe@jakarta.apache.org>
> > > > 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>
> >
> > --
> > To unsubscribe, e-mail:  
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org> For additional
> > commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>

Mime
View raw message