<p dir="ltr">Hello.</p>
<p dir="ltr">I would also add an argument to not add auto-import of IO.*.</p>
<p dir="ltr">It is easy to explain that IO states for input/output, and as a bonus students will get a full list of available IO-methods from IDE suggests. This may encourage them for self learning and won't introduce very special magic for a very few methods.</p>
<p dir="ltr">Regards,<br>
Artyom Drozdov</p>
<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">сб, 9 нояб. 2024 г., 11:03 Cay Horstmann <<a href="mailto:cay.horstmann@gmail.com">cay.horstmann@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am with Stephen here.<br>
<br>
For effective learning, the gating factor is complexity, not verbosity. The regularity of IO.println wins over the implicit import.<br>
<br>
Who are we trying to help with "import static java.io.IO.*"?<br>
<br>
* It's not useful for beginning Java learners.<br>
* It might be useful for advocates to say "look, the canonical Hello World in Java is pretty much like the one in Python". Of course, it really isn't, and removing three letters won't change that.<br>
* It is mildly useful for people (like me) who use Java for scripting tasks.<br>
<br>
I am ok with saying "we want Java to be great for tasks of all sizes, and therefore give you unqualified println, print, readln. Even though we know that is yet another fiddly thing for learners to absorb". Everything is a tradeoff.<br>
<br>
But let's not pretend it makes the language easier to learn. It doesn't.<br>
<br>
Cheers,<br>
<br>
Cay<br>
<br>
<br>
On 08/11/2024 10:20, Stephen Colebourne wrote:<br>
> On Thu, 7 Nov 2024 at 21:10, Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank" rel="noreferrer">brian.goetz@oracle.com</a>> wrote:<br>
>> Here's the bar we're envisioning: methods that are automatically imported in this way _effectively become part of the langauge_.  The bar for that is very high.<br>
> <br>
> Making a method like readInt() "effectively part of the language" is<br>
> clearly wrong. And therefore obvious why it should be rejected.<br>
> But maybe the answer is to take a step back and reconsider whether the<br>
> "automatically imported" part of the sentence is a bad choice (which<br>
> therefore nullifies the "effectively become part of the language"<br>
> claim, effectively allowing readInt and friends).<br>
> <br>
> The JEP ("Growing a program" section) asks users that migrate from a<br>
> simple source file to a normal one to add two imports:<br>
>    import static java.io.IO.*<br>
>    import module java.base<br>
> <br>
> I'm OK with `import module java.base`, but I'm afraid I think `import<br>
> static java.io.IO.*` is a really terrible idea. Most production code<br>
> should not be using the console at all, it should be using some kind<br>
> of logging system. System.out is a hack. IMO, the "growing the<br>
> language" approach described in the JEP will end up over time<br>
> normalising console output in the minds of developers, with a negative<br>
> effect on production Java code.<br>
> <br>
> Given this, and working backwards (IMO):<br>
> - Encouraging `import static java.io.IO.*` is a Really Bad Idea<br>
> - Therefore migrating from simple source file should therefore only<br>
> require `import module java.base`<br>
> - Therefore, simple source files should use IO.println(String), not<br>
> just println(String)<br>
> - Therefore, more methods can be freely added to IO, like readInt()<br>
> <br>
> Yes, yes, yes. I know. `IO.println(String)` is more complex than just<br>
> `println(String)` for a beginner. But is it really that bad for a<br>
> beginner given the risk of normalising console usage?<br>
> <br>
> Stephen<br>
<br>
-- <br>
<br>
Cay S. Horstmann | <a href="https://horstmann.com" rel="noreferrer noreferrer" target="_blank">https://horstmann.com</a><br>
<br>
</blockquote></div>