<p dir="ltr">Hey Stuart,</p>
<p dir="ltr">Thanks for the response. Just to confirm, you are saying that IO.println would have a method that takes in StringTemplates? Or is it a case of calling join on our tenplates, and the IO API remains unchanged?</p>
<p dir="ltr">Either way, StringTemplates are going to have a rippling effect on the Java ecosystem. I'm excited for it.</p>
<br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Mar 7, 2025, 4:14 PM Stuart Marks <<a href="mailto:stuart.marks@oracle.com">stuart.marks@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Our goal with the IO class is to have it add as few mechanisms as possible. Anything <br>
it can do, one should easily be able to do with existing classes like PrintStream or <br>
BufferedReader. So, we wouldn't add a varargs method to IO itself without having one <br>
in PrintStream or something.<br>
<br>
Now, should PrintStream have a varargs overload of println? Well, println first <br>
appeared in JDK 1.0 well before varargs existed and the answer then was to use the + <br>
string concatenation operator for multiple values. This still works, though there <br>
are cases where it doesn't work very well.<br>
<br>
When varargs was added (5.0) PrintStream got printf with varargs, but println wasn't <br>
retrofitted with varargs.<br>
<br>
And there will be string templates, which will allow one to embed multiple values <br>
unobtrusively, so there's no need for varargs here. And a string templates should be <br>
directly usable from IO.println, so it'll come for "free".<br>
<br>
Thus I don't see a need to add varargs overloads here.<br>
<br>
s'marks<br>
<br>
<br>
<br>
On 3/4/25 5:03 AM, David Alayachew wrote:<br>
> Hello Amber Dev Team and Core Libs Dev Team,<br>
> <br>
> Another reddit discussion popped up today about IO.println(), and one of the <br>
> comments mentioned that they wanted something along the lines of this.<br>
> <br>
> IO.println(num1, num2, num3); //prints out "1 2 3"<br>
> <br>
> I proposed that maybe a better option would be a String.join overload. So, instead <br>
> of String.join(String delim, String... elements), there would be String.join(String <br>
> delim, Object... elements), with each object getting toString() called on it.<br>
> <br>
> What are your thoughts on either of these ideas? I actually think the IO.println() <br>
> version is nice, but I felt like String.join made a slightly better compromise.<br>
> <br>
> Another commentor mentioned that this will be easier with String Templates too, so <br>
> maybe it is better to wait for that. I don't think String templates are a bad idea <br>
> here, but it also felt like overkill imo. A library function seems like a better fit.<br>
> <br>
> Thank you for your time and thoughts.<br>
> David Alayachew<br>
<br>
</blockquote></div>