Err. That is solves MY specific problem with char[]'s. If only impedance
mismatch wasn't such a problem with abstractions. I still think it would be
a good idea to get a read-only view of primitives, if it could be
implemented efficiently and transparently.
You're right, that method does what i suggested. Unfortunately it doesn't
seem to help as i thought it would. I wanted to both eliminate the
allocation and any copying done before inserting the String on the Document.
I can eliminate the allocation keeping a buffer for a String bellow a
certain siz
Paulo Levi wrote:
What about adding a method to String complementing the call toCharArray(),
only it takes 3 arguments:
An char array, a position and a length, that inside uses System.arrayCopy.
Isn't that exactly what
String#getChars(0, length, charArray, dstpos)
does?
(see also
http://
What about adding a method to String complementing the call toCharArray(),
only it takes 3 arguments:
An char array, a position and a length, that inside uses System.arrayCopy.
This would create the possibility to eliminate news when we just want to
copy Strings, and still preserve immutability
What about adding a method to String complementing the call toCharArray(),
only it takes 3 arguments:
An char array, a position and a length, that inside uses System.arrayCopy.
This would create the possibility to eliminate news when we just want to
copy Strings, and still preserve immutability.
I'
Hi Paulo,
Am Samstag, den 14.07.2007, 18:52 +0100 schrieb Paulo Levi:
> I'd like to ask if it would be possible to modify the classes of some
> primitive immutable types for returning immutable read only views.
> For example for strings, when using the document hierarchy, any
> insertString in the
I'd like to ask if it would be possible to modify the classes of some
primitive immutable types for returning immutable read only views.
For example for strings, when using the document hierarchy, any insertString
in the GapContent object invokes str.toCharArray(), that
is implemented like this:
p
