+1
to Benedict and Martin
-Ulf
Am 12.04.2012 11:35, schrieb Martin Desruisseaux:
Le 12/04/12 10:57, Benedict Elliott Smith a écrit :
I think in this case it is reasonable to leave it to the user to ensure
that the input remains consistent for the duration of the call. It can be
documented if n
Le 12/04/12 10:57, Benedict Elliott Smith a écrit :
I think in this case it is reasonable to leave it to the user to ensure
that the input remains consistent for the duration of the call. It can be
documented if necessary, but as I say I think all imperative methods come
with that caveat by defin
>
> Remi and I have in the past had differences of opinion on the utility of
> introducing CharSequence versions of such methods.
>
> One benefit to using a string is that the object is immutable; there are
> no time-of-check-versus-time-of-**use conditions to worry about. Robust
> code should arg
On 4/11/2012 7:45 AM, Rémi Forax wrote:
On 04/11/2012 04:18 PM, Benedict Elliott Smith wrote:
Hi,
Looking at the source code, it doesn't appear as though there is any
reason
to require the input be a String - only length() and charAt() are
called,
which are both declared by CharSequence. Is t
Sounds like a perfectly good reason! - and also that it should be a
relatively safe change to implement. Any volunteers? I'd be happy to, but I
expect the overhead for having a non-contributor do it would exceed the
actual work by several orders of magnitude.
On 11 April 2012 15:45, Rémi Forax wr
On 04/11/2012 04:18 PM, Benedict Elliott Smith wrote:
Hi,
Looking at the source code, it doesn't appear as though there is any reason
to require the input be a String - only length() and charAt() are called,
which are both declared by CharSequence. Is there a reason I can't fathom,
or was it an
