<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 2/6/24 13:05, Brian Goetz wrote:<br>
</div>
<blockquote type="cite"
cite="mid:38766d81-5de5-4110-b086-5c8f39bbb88a@oracle.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
I'll just add one more point to try and illustrate why it makes me
uncomfortable. In the python example:<br>
<br>
print(f'Hello {name}, your balance is {balance}')<br>
<br>
there are two mechanisms here -- f-strings and print(). And the
two are completely orthogonal; I can put any string I want inside
the parens and it works, and I can take the f-string and put the
result wherever I can put a string. Each can be designed
independently, and reasoned about independently, and they meet at
the String type, and because of that, they compose with no
additional coordination. <br>
<br>
The string processor suggested here complects two things that
should be orthogonal: string interpolation and writing to stdout.
If I want to write to std out without interpolation (maybe I
already have a string in hand), or I want to interpolate without
printing, now I have to use another mechanism. So it can't
replace either println *or* STR, and that means people have to
learn all three. Whereas the status quo is more like the python
example: we have template expressions using STR in the place of
f-strings, and we have a method that takes any string and prints
it. The main defect of the status quo is the confusing rules
surrounding qualification, but fixing that by denormalizing what
is already a sensible separation of concerns is one step forward
and two steps back. Instead, we should address the qualification
problem more directly. <br>
</blockquote>
<p>You are, as usual, quite right. Therefore, one possible way to
take it head on: in the System class, redefine "out" along the
following lines (I realize that System.out is more complicated but
this is the sketch):<br>
</p>
<p>public static PrintStream out = new PrintStream() {<br>
| public static void PRINT(String line) { println(line); }<br>
};<br>
</p>
<p>and have this System.out.PRINT be auto-statically imported, like
STR is (y first thought was just to add the method to PrintStream,
but that would pollute the latter's namespace).<br>
</p>
<p>It avoids confounding the two ideas and paves over the rules
about qualification.</p>
<p>Students will learn soon enough that System.out.println() can be
used (when they start reading old code), but they don't have to
learn it up front.</p>
<blockquote type="cite"
cite="mid:38766d81-5de5-4110-b086-5c8f39bbb88a@oracle.com"> <br>
<br>
<br>
<div class="moz-cite-prefix">On 2/6/2024 12:41 PM, Ian Darwin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:31854059-5dfc-4bda-820d-796af3bfd046@darwinsys.com">
<div class="moz-cite-prefix">I see your main point but can't
resist the odd quibble:</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 2/6/24 12:14, Brian Goetz wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d7bc4651-fe92-4191-ad50-423109969e75@oracle.com"> <font
size="4" face="monospace">Similar things have been suggested
before, but there are two primary concerns here that make it
a "clever" but unattractive-in-the-long-term direction.<br>
<br>
The main one is "the onramp should lead to the highway." If
we give a special, magic way to print templated strings, but
nothing else, this is an easy incantation to teach, but it
doesn't go very far. If you want to do even a little bit
more (e.g., print to a file, or to standard error, or just
print out a string with no formatting, etc), you have to
switch to a completely different mechanism, </font></blockquote>
<p>A string with no formatting would be handled like any other,
just as STR."Hello world" yields (redundantly) a string with
no formatting.<br>
</p>
<p>Printing to a file is more complicated anyway as you don't
usually get there without meeting IOException and try/catch or
at least throws.</p>
<p>But yes, it is a different mechanism; as part of smoothing
that out, students can initially be taught that PRINT."..." is
"just a shortcut" for System.out.println(STR."..."); as a side
benefit, they learn about this string template that can be
used anywhere.<br>
</p>
<blockquote type="cite"
cite="mid:d7bc4651-fe92-4191-ad50-423109969e75@oracle.com"><font
size="4" face="monospace">and now you need to know TWO
things and know when to use one or the other. It is a
shortcut that becomes a "beginner's dialect" because it does
not lead smoothly to learning the "regular" language. <br>
<br>
Second, the possibility that a string template could have
side-effects instead of (or worse, in addition to) just
taking the ingredients and mixing them up into a composite
thing makes the concept of string templates more
complicated. While we can't prevent people from sneaking
side effects into their template processors, we shouldn't
encourage this, or suggest that all users have to work this
into their mental model. </font></blockquote>
<font size="4" face="monospace">But this template processor,
like STR itself, would be a final field in perhaps the
StringTemplate class, imported automatically like STR. It is
your processor, not theirs.</font><br>
<blockquote type="cite"
cite="mid:d7bc4651-fe92-4191-ad50-423109969e75@oracle.com"><font
size="4" face="monospace"> <br>
<br>
So its possible, but I don't think its a good direction for
the language. <br>
</font></blockquote>
<font size="4" face="monospace">It's your call. Thanks for the
feedback. I'll withdraw the suggestion and hope that some day,
some way can be found to simplify this particular "speed
bump". I respect that the team always holds off until the best
or "correct" way can be found.</font><br>
<blockquote type="cite"
cite="mid:d7bc4651-fe92-4191-ad50-423109969e75@oracle.com"><font
size="4" face="monospace"> </font><br>
<div class="moz-cite-prefix">On 2/6/2024 11:54 AM, Ian Darwin
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:26d5a32b-338a-4aae-944e-a86378ce90a5@darwinsys.com">While
experimenting with the String Template feature, it occurs to
me that a relatively simple expansion of String Templates
would pave over another of those speed bumps. Basically:
<p> PRINT."Hello \{name}. Your balance is \{amount}";</p>
<p>Indeed, the beginner who hasn't yet met string templates
can use the degenerate case</p>
<p> PRINT."Hello world";</p>
<p>and then later "need not discard what they learned in the
early stages, but rather they see how it all fits within
the larger picture."</p>
<p>This compares favorably with, e.g., Python 3's </p>
<p>print('Hello world') and </p>
<p>print(f'Hello {name}, your balance is {balance}')<br>
</p>
<p>This seems like a fairly obvious extension, so I ask: Do
you already have such a thing up your collective sleeves
or, if not, do you think it might be grounds for a JEP
proposal?<br>
</p>
</blockquote>
<br>
</blockquote>
<p><br>
</p>
</blockquote>
<br>
</blockquote>
<p><br>
</p>
</body>
</html>