Henri Yandell wrote:
Must be linked to which method was which.

chomp x:       cut off x and everything after it
prechomp x:    cut off x and everything before it
getChomp x:    return the inverse of chomp x
getPrechomp x: return the inverse of prechomp x

chomp       -> slice  [chomp changed to meet perl chomp]
prechomp    -> sliceFirstRemainder
getPrechomp -> sliceFirst
getChomp    -> sliceRemainder

So, sliceFirst and sliceFirstRemainder still have the intent for being
inverses so that sliceFirst( s, x ) + sliceFirstRemainder( s, x ) == s.

Not exactly true, since neither sliceFirst nor sliceFirstRemainder returns the delimiter, but what is true in the current implementation is that for any strings x, s, t (including null, "" anywhere)


sliceFirst(s^x^t, x) + sliceFirstRemainder(s^x^t, x) = s^t

The question is, is this symmetry worth the strange definition (at least strange to me) of sliceFirstRemainder which returns the full string when it does not include the delimiter.

My recomendation would be to agree on what it means for "x to occur in s" in each of the following cases and then make the slice implementations follow their top line definitions based on this consistent (documented, of course :-) definition. In each case, I have put my HO in parens. Basically, my HO just amounts to being consistent with indexOf, lastIndexOf. Javadoc could provide "formulas" making this explicit.

s null (all slices return null)

s empty (all slices return "")

s nontrivial, x nontrivial, s contains x (natural definitions)

s nontrivial, x nontrivial, s does not contain x (there is no first or last occurrence, so "all characters before the first occurrence" = s and "all characters after the last occurrence" = "")

s nontrivial, x null (s does not contain x, so same as previous)

s nontrivial, x empty (s occurs both at the beginning of x and at the end of x, so "all characters before the first occurrence" = "" =
"all characters after the last occurrencce")


Sorry to open up this can of worms just now. Bad timing, but good to get it out on the table. I will provide a patch to make and document the changes above if we want to go this route.

One important disclaimer: I never bonded with Perl and I have no idea how closely the above defs would match Perl behavior.

Phil



Whether this should still hold though now, I don't know. Although I felt that chomp+getChomp should = s, I always found it made getChomp a bit painful to use as it returned the delimiter itself. I think I was overly impressed with the symmetry.

Hen


On Wed, 23 Jul 2003, Stephen Colebourne wrote:



OK, the current behaviour seems daft to me. Can anyone explain why this is
as it is?

StringUtils.sliceFirst("abc", "") = "abc"
StringUtils.sliceFirst("abc", "d") = ""

StringUtils.sliceFirstRemainder("abc", "") = ""
StringUtils.sliceFirstRemainder("abc", "d") = "abc"

I would expect the exact opposite:
StringUtils.sliceFirst("abc", "") = ""
StringUtils.sliceFirst("abc", "d") = "abc"

StringUtils.sliceFirstRemainder("abc", "") = "abc"
StringUtils.sliceFirstRemainder("abc", "d") = ""


I would expect slice first to return the text before the first separator. An empty string is found at position zero, so it should return "". Separator "d" is not found, so everything before it is the whole string.

I'd like to change this, but why is it as it is???

Stephen

----- Original Message -----
From: "Phil Steitz" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 3:30 PM
Subject: Re: [lang] StringUtils.sliceFirstRemainder behavior



Stephen Colebourne wrote:

I think I would expect:

StringUtils.slice("foo", "b") = "foo"
"get everything before the last 'b'"

StringUtils.sliceRemainder("foo", "b") = ""
"get everything after the last 'b'"

StringUtils.sliceFirst("foo", "b") = ""
"get everything before the first 'b'"

StringUtils.sliceFirstRemainder("foo", "b") = "foo"
"get everything after the first 'b'"

slice and sliceRemainder are opposite.
The results would be the same for a blank separator.

But then I don't use Perl which is where I think these came from.
So wait to see if you get any more answers!

Stephen


I just submitted a patch here


http://issues.apache.org/bugzilla/show_bug.cgi?id=21797

that documents current behavior with examples and test cases.

Phil


----- Original Message -----
From: "Phil Steitz" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 5:50 AM
Subject: [lang] StringUtils.sliceFirstRemainder behavior




Currently,

StringUtils.sliceRemainder("foo", "b") = ""
= StringUtils.sliceFirst("foo", "b"),

but StringUtils.sliceRemainder("foo", "b") = "foo".

Is this the intended behavior?

Phil




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to