Hi Mike,
Yes, all that you say below is true. CharSequence is an interface that does
not define the contract of identity when implementations/subtypes of
CharSequence do - each in it's own way. Much like java.util.Collection and
List vs. Set. It's always dangerous for methods that return such
If String.substring(int, int) now performs a copy of the underlying
char[] array and if there is no String.subSequence(int, int) providing
the old functionality, maybe the following implications should be
investigated?
StringBuilder.append(...)
Since, in order to avoid a
On Jun 26 2012, at 07:13 , Martin Desruisseaux wrote:
If String.substring(int, int) now performs a copy of the underlying char[]
array and if there is no String.subSequence(int, int) providing the old
functionality, maybe the following implications should be investigated?
Le 26/06/12 20:10, Mike Duigou a écrit :
StringBuilder.append(string.substring(lower, upper));
by:
StringBuilder.append(string, lower, upper);
This would seem to be a good refactoring regardless of the substring
implementation as it avoids creation of a temporary object.
The
On 22/06/2012 23:15, Mike Duigou wrote:
:
- The CharSequences returned by subSequence would follow only the general
CharSequence rules for equals()/hashCode(). Any current usages of the result of
subSequence for equals() or hashing, even though it's not advised, would break.
We could add
Mike, Why not implement subSequence as 'java.nio.CharBuffer.wrap(data,
beginIndex, endIndex).asReadOnlyBuffer()' ? Easy to implement and test. The
nice thing is that parsers would know what a 'CharBuffer' vs. a sub sequence
String internal class. Jason
Subject: String.subSequence and
As usual, an excellent idea Jason. I'll probably run an internal test/benchmark
with both this and the CharSequence inner class implementation to see what
breaks and where there are performance differences between the two. I was
planning to also test a version of the CharSequence implementation
