You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <gg...@seagullsw.com> on 2003/12/15 02:52:32 UTC

[lang] How to best address Bug 25454 - Part 2

It seems that the consensus is to just fix StringUtils.replaceChars(S,S,S),
so I have done so.

I have added a couple more unit tests to cover more of the Javadoc examples
and the example cited in the email thread.

Please note the following: the pre-fix unit tests asserted that if an input
string was not "modified" (in quotes since Java String are immutable), the
return String had to be the "same" (Assert.assertSame as opposed to
Assert.assertEquals). The current impl return a new string from the working
buffer even if no replace took place. The Javadoc contract does not specify
the old behavior or even hint at it, the only mention of returning the input
string is if it or the search chars are empty. Please let me know if you
think this is a problem.

Thank you,
Gary

Re: [lang] How to best address Bug 25454 - Part 2

Posted by Phil Steitz <ph...@steitz.com>.
Gary Gregory wrote:
> It seems that the consensus is to just fix StringUtils.replaceChars(S,S,S),
> so I have done so.

Looks good to me.

> 
> I have added a couple more unit tests to cover more of the Javadoc examples
> and the example cited in the email thread.
> 
> Please note the following: the pre-fix unit tests asserted that if an input
> string was not "modified" (in quotes since Java String are immutable), the
> return String had to be the "same" (Assert.assertSame as opposed to
> Assert.assertEquals). The current impl return a new string from the working
> buffer even if no replace took place. The Javadoc contract does not specify
> the old behavior or even hint at it, the only mention of returning the input
> string is if it or the search chars are empty. Please let me know if you
> think this is a problem.

I have no problem with returning a copy from the buffer in all cases.

Phil

> 
> Thank you,
> Gary




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org