You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by John Yu <jo...@scioworks.com> on 2002/08/26 11:55:19 UTC
[lang] Proposed addition to StringUtils
Both StringUtils.isEmpty() and StringUtils.isNotEmpty() treats null as
empty string. To be consistent with this semantics, how about overload
StringUtils.equals():
public static boolean equals(String str1, String str2,
boolean treatNullAsEmptyString)
{
if(treatNullAsEmptyString && isEmpty(str1) && isEmpty(str2)) {
return true;
}
return (str1 == null ? str2 == null : str1.equals(str2));
}
To maintain backward compatibility, make the existing equals(s1, s2) to
call equals(s1, s2, false).
Apart from semantical consistency, I find I do this logic pretty often.
--
John Yu Scioworks Technologies
e: john@scioworks.com w: +(65) 873 5989
w: http://www.scioworks.com m: +(65) 9782 9610
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Proposed addition to StringUtils
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Steven Caswell" <st...@caswell.name> writes:
> I'm not convinced a separate method is warranted, though I guess my
> alternative could be a little verbose. I definitely don't like the flag
> approach, but if we reach a concensus on clear naming I won't block it.
> I'm not sure if Bugzilla is appropriate or not at this point (hopefully
> someone with more experience can give direction on that).
Filing an issue is definite appropriate.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [lang] Proposed addition to StringUtils
Posted by Steven Caswell <st...@caswell.name>.
I'm not convinced a separate method is warranted, though I guess my
alternative could be a little verbose. I definitely don't like the flag
approach, but if we reach a concensus on clear naming I won't block it.
I'm not sure if Bugzilla is appropriate or not at this point (hopefully
someone with more experience can give direction on that).
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: John Yu [mailto:john@scioworks.com]
> Sent: Monday, August 26, 2002 8:45 PM
> To: Jakarta Commons Developers List
> Subject: RE: [lang] Proposed addition to StringUtils
>
>
> At 04:17 am 27-08-2002, you wrote:
> >I agree with Daniel. I'm not a particular fan of using flags in the
> >argument list to alter the behavior of an operation.
> >
> >Couldn't the desired effect be achieved by the caller by using the
> >StringUtils.defaultString method on each argument to equals?
> Something
> >like
> >
> >StringUtils.equals(StringUtils.defaultString(str1),
> >StringUtils.defaultString(str2))
>
>
> Yes, this does the work. But it gets verbose.
> (You see, the email client had to break it up into two lines. :-)
>
> As I find I do this pretty often, I think such cosmetic
> simplification is
> useful. Any other suggestion? Or do you think it is really redundant?
> Actually, using a different method name can avoid using a
> flag. But I'm
> lack of the imagination to think of a method name.
>
> What about I file an enhancement in Buzilla so that we can
> come back to
> this later after the release?
> --
> John
>
>
> >Steven Caswell
> >
> > > -----Original Message-----
> > > From: dlr@finemaltcoding.com [mailto:dlr@finemaltcoding.com]
> > > Sent: Monday, August 26, 2002 11:38 AM
> > > To: Jakarta Commons Developers List
> > > Subject: Re: [lang] Proposed addition to StringUtils
> > >
> > >
> > > John Yu <jo...@scioworks.com> writes:
> > >
> > > > Both StringUtils.isEmpty() and StringUtils.isNotEmpty()
> > > treats null as
> > > > empty string. To be consistent with this semantics, how
> > > about overload
> > > > StringUtils.equals():
> > > >
> > > >
> > > > public static boolean equals(String str1, String str2,
> > > > boolean treatNullAsEmptyString)
> > > > {
> > > > if(treatNullAsEmptyString && isEmpty(str1) &&
> isEmpty(str2)) {
> > > > return true;
> > > > }
> > > > return (str1 == null ? str2 == null : str1.equals(str2));
> > > > }
> > > >
> > > > To maintain backward compatibility, make the existing
> > > equals(s1, s2)
> > > > to call equals(s1, s2, false).
> > > >
> > > >
> > > > Apart from semantical consistency, I find I do this
> logic pretty
> > > > often.
> > >
> > > I wouldn't be a fan of this change, mainly on the
> argument that it
> > > isn't Java-like.
> > > --
> > > Daniel Rall <dl...@finemaltcoding.com>
>
> --
> John Yu Scioworks Technologies
> e: john@scioworks.com w: +(65) 873 5989
> w: http://www.scioworks.com m: +(65) 9782 9610
>
> Scioworks Camino - "Don't develop Struts Apps without it!"
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [lang] Proposed addition to StringUtils
Posted by John Yu <jo...@scioworks.com>.
At 04:17 am 27-08-2002, you wrote:
>I agree with Daniel. I'm not a particular fan of using flags in the
>argument list to alter the behavior of an operation.
>
>Couldn't the desired effect be achieved by the caller by using the
>StringUtils.defaultString method on each argument to equals? Something
>like
>
>StringUtils.equals(StringUtils.defaultString(str1),
>StringUtils.defaultString(str2))
Yes, this does the work. But it gets verbose.
(You see, the email client had to break it up into two lines. :-)
As I find I do this pretty often, I think such cosmetic simplification is
useful. Any other suggestion? Or do you think it is really redundant?
Actually, using a different method name can avoid using a flag. But I'm
lack of the imagination to think of a method name.
What about I file an enhancement in Buzilla so that we can come back to
this later after the release?
--
John
>Steven Caswell
>
> > -----Original Message-----
> > From: dlr@finemaltcoding.com [mailto:dlr@finemaltcoding.com]
> > Sent: Monday, August 26, 2002 11:38 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [lang] Proposed addition to StringUtils
> >
> >
> > John Yu <jo...@scioworks.com> writes:
> >
> > > Both StringUtils.isEmpty() and StringUtils.isNotEmpty()
> > treats null as
> > > empty string. To be consistent with this semantics, how
> > about overload
> > > StringUtils.equals():
> > >
> > >
> > > public static boolean equals(String str1, String str2,
> > > boolean treatNullAsEmptyString)
> > > {
> > > if(treatNullAsEmptyString && isEmpty(str1) && isEmpty(str2)) {
> > > return true;
> > > }
> > > return (str1 == null ? str2 == null : str1.equals(str2));
> > > }
> > >
> > > To maintain backward compatibility, make the existing
> > equals(s1, s2)
> > > to call equals(s1, s2, false).
> > >
> > >
> > > Apart from semantical consistency, I find I do this logic pretty
> > > often.
> >
> > I wouldn't be a fan of this change, mainly on the argument
> > that it isn't Java-like.
> > --
> > Daniel Rall <dl...@finemaltcoding.com>
--
John Yu Scioworks Technologies
e: john@scioworks.com w: +(65) 873 5989
w: http://www.scioworks.com m: +(65) 9782 9610
Scioworks Camino - "Don't develop Struts Apps without it!"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [lang] Proposed addition to StringUtils
Posted by Steven Caswell <st...@caswell.name>.
I agree with Daniel. I'm not a particular fan of using flags in the
argument list to alter the behavior of an operation.
Couldn't the desired effect be achieved by the caller by using the
StringUtils.defaultString method on each argument to equals? Something
like
StringUtils.equals(StringUtils.defaultString(str1),
StringUtils.defaultString(str2))
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: dlr@finemaltcoding.com [mailto:dlr@finemaltcoding.com]
> Sent: Monday, August 26, 2002 11:38 AM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] Proposed addition to StringUtils
>
>
> John Yu <jo...@scioworks.com> writes:
>
> > Both StringUtils.isEmpty() and StringUtils.isNotEmpty()
> treats null as
> > empty string. To be consistent with this semantics, how
> about overload
> > StringUtils.equals():
> >
> >
> > public static boolean equals(String str1, String str2,
> > boolean treatNullAsEmptyString)
> > {
> > if(treatNullAsEmptyString && isEmpty(str1) && isEmpty(str2)) {
> > return true;
> > }
> > return (str1 == null ? str2 == null : str1.equals(str2));
> > }
> >
> > To maintain backward compatibility, make the existing
> equals(s1, s2)
> > to call equals(s1, s2, false).
> >
> >
> > Apart from semantical consistency, I find I do this logic pretty
> > often.
>
> I wouldn't be a fan of this change, mainly on the argument
> that it isn't Java-like.
> --
>
> Daniel Rall <dl...@finemaltcoding.com>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Proposed addition to StringUtils
Posted by Daniel Rall <dl...@finemaltcoding.com>.
John Yu <jo...@scioworks.com> writes:
> Both StringUtils.isEmpty() and StringUtils.isNotEmpty() treats null as
> empty string. To be consistent with this semantics, how about overload
> StringUtils.equals():
>
>
> public static boolean equals(String str1, String str2,
> boolean treatNullAsEmptyString)
> {
> if(treatNullAsEmptyString && isEmpty(str1) && isEmpty(str2)) {
> return true;
> }
> return (str1 == null ? str2 == null : str1.equals(str2));
> }
>
> To maintain backward compatibility, make the existing equals(s1, s2)
> to call equals(s1, s2, false).
>
>
> Apart from semantical consistency, I find I do this logic pretty often.
I wouldn't be a fan of this change, mainly on the argument that it
isn't Java-like.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>