<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
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>
<br>
<br>
<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>
</body>
</html>