commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Elkins <chr...@scardini.com>
Subject Re: [PATCH][lang] Minor clean-up of Strings.split()
Date Fri, 21 Jun 2002 07:19:09 GMT

On Thursday, June 20, 2002, at 10:19  PM, Henri Yandell wrote:

>
> Looks good. Why number 2? It doesn't hurt, but I'm not sure if it's any
> form of real improvement.
>
> ie) Why -1 to any negative number and not just some form of Constant?
>
> Hen
>
> On Thu, 20 Jun 2002, Christopher Elkins wrote:
>
>> Hi, all.
>>
>> The attached patch does two things that IMO make the behavior of
>> Strings.split() a little more intuitive.
>>
>> 1. Change the default delimiter to any whitespace from its current
>> default of a single space character. This brings split() in line
>> with the default behavior of java.util.StringTokenizer and both
>> Perl and Python's implementation of split().
>>
>> 2. Instead of using a magic number to indicate "no limit", accept
>> any non-positive value to indicate as such. (The patch also adds a
>> couple tests for the corner cases).

Two reasons:

1) In this context -1 has no intrinsic semantic value; it is just a 
way for the caller to indicate that it wants an array large enough 
to hold all tokens. As such, there is really no difference between 
-1, -1001, or any other arbitrary negative value. However, by only 
accepting a _specific_ arbitrary negative value, the method's 
behavior for every other negative value remains undefined. 
Undefined behavior is acceptable if there exists a valid reason why 
it cannot be defined (and if it is clearly documented), but that is 
not the case here.

2) This is how Perl does it, so I guess that's some sort of 
precedent - not that I implicitly condone every Perl idiom. ;-)

--
Christopher Elkins


--
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