Request for Comments: Adding bulk-read method "CharSequence.getChars(int srcBegin, int srcEnd, char[] dst, int dstBegin)"

[Markus KARG]

Thank you, everybody. As no more comments arrived in the past eight 
weeks, I assume that there is implicit agreement with my latest 
arguments (see below), so next I will provide a PR to continue 
discussion with real Java code at hand.

-Markus


Am 01.12.2024 um 19:23 schrieb Markus Karg:
>
> As Thanksgiving is over, and as work towards 24-RDP1 should mostly be 
> done, I think it is a good time to resume our now.
>
> To kick-off, below I am repeating my last response to Chen. Kindly 
> asking everybody to chime in, so we can find a feasible and beneficial 
> conclusion in this area.
>
> -Markus
>
> *Von:*Markus Karg [mailto:markus at headcrashing.eu]
> *Gesendet:* Sonntag, 27. Oktober 2024 09:44
> *An:* 'core-libs-dev'
> *Betreff:* Request for Comments: Adding bulk-read method 
> "CharSequence.getChars(int srcBegin, int srcEnd, char[] dst, int 
> dstBegin)"
>
> >Hi Markus,
>
> >Should we drop the srcBigin/srcEnd parameters, as they can be replaced by a 
> subSequence(srcBegin, srcEnd) call?
>
> Chen, I do understand your idea and while originally I had the same in 
> mind (it really /is/ appealing!), I came up with a draft using the 
> *original* String.getChars()signature instead, due to the following 
> drawbacks:
>
>   * There might exist (possibly lotsof) CharSequence.getChars(int,
>     int, char[], int)implementations already, as this problem (and the
>     idea how to solve it) is anything but new. At least such
>     implementations are String, StringBuilderand StringBuffer. If we
>     come up with a different signature, then *none* of these already
>     existing performance boosters will get used by
>     Reader.of(CharSequence)automatically - at least until they come up
>     with alias methods. Effectively this leads to (possibly lots) of
>     alias methods. At least it leads to alias methods in String,
>     StringBuilder, StringBufferand CharBuffer. In contrast, when
>     keeping the signature copied from String.getChars, chances are
>     good that (possibly lots of) implementations will /instantly/ be
>     supported by Reader.of(CharSequence)without alias methods. At
>     least, String, StringBuilderand StringBufferwill be.
>   * Since decades people are now very used to
>     StringBuilder.getChars(int, int, char[], int), so (possibly a lot
>     of) people might simply /expect/ us to come up with that lengthy
>     signature. These people might be rather confused (if not to say
>     frustrated) when we now force them to write an intermediate
>     subSequence(int, int)for something that was "such simple" before.
>   * Custom implementations of CharSequence.subSequencecould come up
>     with the (performance-wise "bad") idea of creating *copies*
>     instead of views. At least it seems like AbstractStringBuilderis
>     doing that, so chances are "good" that custom libs will do that,
>     too. For example, because they need it for safety. Or possibly,
>     because they have a technical reason that /enforces/ a copy. That
>     would (possibly massively, depending on the actual class) spoil
>     the idea of performance-boosting this RFC is all about.
>
> -Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250209/e3c814c2/attachment.htm>