<div dir="auto"><div>Hello Markus,</div><div dir="auto"><br></div><div dir="auto">I am ignorant about the larger topic, so I will only respond to the following point.</div><div dir="auto"><br></div><div dir="auto">> 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.</div><div dir="auto"><br></div><div dir="auto">No.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br><div class="gmail_quote gmail_quote_container" dir="auto"><div dir="ltr" class="gmail_attr">On Sun, Feb 9, 2025, 1:35 PM Markus KARG <<a href="mailto:markus@headcrashing.eu">markus@headcrashing.eu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div>
<p>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.</p>
<p>-Markus</p>
<p><br>
</p>
<div>Am 01.12.2024 um 19:23 schrieb Markus
Karg:<br>
</div>
<blockquote type="cite">
<div>
<p class="MsoNormal"><span style="color:#1f497d">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">-Markus<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><a name="m_-8345689851884398006__MailEndCompose" rel="noreferrer"><span style="color:#1f497d"><u></u> <u></u></span></a></p>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">Von:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Markus Karg [<a href="mailto:markus@headcrashing.eu" target="_blank" rel="noreferrer">mailto:markus@headcrashing.eu</a>] <br>
<b>Gesendet:</b> Sonntag, 27. Oktober 2024 09:44<br>
<b>An:</b> 'core-libs-dev'<br>
<b>Betreff:</b> Request for Comments: Adding bulk-read
method "CharSequence.getChars(int srcBegin, int srcEnd,
char[] dst, int dstBegin)"<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">>Hi
Markus,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Courier New"">>Should
we drop the srcBigin/srcEnd parameters, as they can be
replaced by a subSequence(srcBegin, srcEnd) call?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">Chen,
I do understand your idea and while originally I had the
same in mind (it really <i>is</i> appealing!), I came up
with a draft using the <b>original</b> </span><span style="font-size:10.0pt;font-family:"Courier New"">String.getChars()</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">
signature instead, due to the following drawbacks:<u></u><u></u></span></p>
<ul type="disc">
<li class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">There
might exist (possibly lotsof) </span><span style="font-size:10.0pt;font-family:"Courier New"">CharSequence.getChars(int,
int, char[], int)</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">
implementations already, as this problem (and the idea how
to solve it) is anything but new. At least such
implementations are </span><span style="font-size:10.0pt;font-family:"Courier New"">String</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">,
</span><span style="font-size:10.0pt;font-family:"Courier New"">StringBuilder</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">
and </span><span style="font-size:10.0pt;font-family:"Courier New"">StringBuffer</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">.
If we come up with a different signature, then <b>none</b>
of these already existing performance boosters will get
used by </span><span style="font-size:10.0pt;font-family:"Courier New"">Reader.of(CharSequence)</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">
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 </span><span style="font-size:10.0pt;font-family:"Courier New"">String</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">,
</span><span style="font-size:10.0pt;font-family:"Courier New"">StringBuilder</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">,
</span><span style="font-size:10.0pt;font-family:"Courier New"">StringBuffer</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">
and </span><span style="font-size:10.0pt;font-family:"Courier New"">CharBuffer</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">.
In contrast, when keeping the signature copied from </span><span style="font-size:10.0pt;font-family:"Courier New"">String.getChars</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">,
chances are good that (possibly lots of) implementations
will <i>instantly</i> be supported by </span><span style="font-size:10.0pt;font-family:"Courier New"">Reader.of(CharSequence)</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">
without alias methods. At least, </span><span style="font-size:10.0pt;font-family:"Courier New"">String</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">,
</span><span style="font-size:10.0pt;font-family:"Courier New"">StringBuilder</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">
and </span><span style="font-size:10.0pt;font-family:"Courier New"">StringBuffer</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">
will be.<u></u><u></u></span></li>
<li class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">Since
decades people are now very used to </span><span style="font-size:10.0pt;font-family:"Courier New"">StringBuilder.getChars(int,
int, char[], int)</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">,
so (possibly a lot of) people might simply <i>expect</i>
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 </span><span style="font-size:10.0pt;font-family:"Courier New"">subSequence(int,
int)</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">
for something that was "such simple" before.<u></u><u></u></span></li>
<li class="MsoNormal"><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">Custom
implementations of </span><span style="font-size:10.0pt;font-family:"Courier New"">CharSequence.subSequence</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">
could come up with the (performance-wise "bad") idea of
creating <b>copies</b> instead of views. At least it
seems like </span><span style="font-size:10.0pt;font-family:"Courier New"">AbstractStringBuilder</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif"">
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 <i>enforces</i> a copy. That would (possibly
massively, depending on the actual class) spoil the idea
of performance-boosting this RFC is all about.<u></u><u></u></span></li>
</ul>
<p class="MsoNormal"><span style="color:#1f497d">-Markus<u></u><u></u></span></p>
</div>
</blockquote>
</div>
</blockquote></div></div></div>