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

[David Alayachew]

Hello Markus,

I am ignorant about the larger topic, so I will only respond to the
following point.

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

No.

In general, it's considered a faux pas to try and make a PR before getting
the thumb's up from at least a few people via the mailing lists. If people
have concerns about the design, the intent is to continue hashing it out on
the mailing lists until they have been addressed. Making a PR before those
issues are resolved is considered premature.

And if there is a general sense of no-response, you can knock the door a
few times, but after that, no-response should be interpreted as rejection
if the above points aren't dealt with.

On Sun, Feb 9, 2025, 1:35 PM Markus KARG <markus at headcrashing.eu> wrote:

> 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 <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, StringBuilder and 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, StringBuffer and 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,
>    StringBuilder and StringBuffer will 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.subSequence could come up
>    with the (performance-wise "bad") idea of creating *copies* instead of
>    views. At least it seems like AbstractStringBuilder is 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/79db5475/attachment-0001.htm>