Hi,
Our goal with the IO class is to have it add as few mechanisms as possible. Anything
it can do, one should easily be able to do with existing classes like PrintStream or
BufferedReader. So, we wouldn't add a varargs method to IO itself without having one
in PrintStream or something.
Now, should PrintStream have a varargs overload of println? Well, println first
appeared in JDK 1.0 well before varargs existed and the answer then was to use the +
string concatenation operator for multiple values. This still works, though there
are cases where it doesn't work very well.
When varargs was added (5.0) PrintStream got printf with varargs, but println wasn't
retrofitted with varargs.
And there will be string templates, which will allow one to embed multiple values
unobtrusively, so there's no need for varargs here. And a string templates should be
directly usable from IO.println, so it'll come for "free".
Thus I don't see a need to add varargs overloads here.
s'marks
On 3/4/25 5:03 AM, David Alayachew wrote:
Hello Amber Dev Team and Core Libs Dev Team,
Another reddit discussion popped up today about IO.println(), and one of the
comments mentioned that they wanted something along the lines of this.
IO.println(num1, num2, num3); //prints out "1 2 3"
I proposed that maybe a better option would be a String.join overload. So, instead
of String.join(String delim, String... elements), there would be String.join(String
delim, Object... elements), with each object getting toString() called on it.
What are your thoughts on either of these ideas? I actually think the IO.println()
version is nice, but I felt like String.join made a slightly better compromise.
Another commentor mentioned that this will be easier with String Templates too, so
maybe it is better to wait for that. I don't think String templates are a bad idea
here, but it also felt like overkill imo. A library function seems like a better fit.
Thank you for your time and thoughts.
David Alayachew
