3 ms·

JEP Draft: String Templates (Final)

19 points by mfiguiere 3y ago

mfiguiere 3y ago
> Feedback from JDK 21 suggested that String Templates should be finalized for JDK 22.
- jiehong 3y ago
  Would be nice if they detailed the received feedback.
rf15 3y ago
Even after reading this proposal over the past months over and over in all its iterations, I still don't get it. Is this what many developers want? I fear people will just stick with +concatenation because it's less verbose than this.
- LatticeAnimal 3y ago
  STR.”what is so bad about \{this}?”
  - rf15 3y ago
    `"what is so bad about" + this` uses 4 less characters, and that includes the spaces around the plus.
    - quacker 3y ago
      Except it’s more if I have text following a variable. Try this: STR.”x=\{x} y=\{y} z=\{z}.” Compared to: “x=“ + x + “ y=“ + y + “ z=“ + z + “.” A string template incurs an overhead of 3 characters per variable (“\“, “{“, and “}”) plus the leading “STR.”, which is 4 characters. Concatenation incurs an overhead of 4 non-whitespace characters per variable (`”+` and `+”`), and that’s ignoring whitespace. If you have more than 3-4 variables, string templates are shorter. The concatenation example is less readable as well. Have I included whitespace to exactly match the string template example? It’s a little hard to tell at a glance because I have to distinguish what is code whitespace and what’s included in the string.
    - BenoitP 3y ago
      You may have a point for strings. But this is about guarantees for more convoluted expressions in other languages. If you include validating SQL being injection-free, this is waaay less verbose. Also this is about enabling a _system_ of templating, and potentially letting the IDE treat it as such and warn you at compile-time. Small snippets tend to creep all over a codebase. Some use-case that this enables: * HTML templating React-server-side-style: response.send(HTML_PART."""<div>\{name}</div>"""). Here both the HTML is validated, and the variable is escaped; at compile-time. How do you beat this? * Query-building: businessFilterClause.add(WHERE_VALIDATE."""PRODUCT_MODEL IN \{authorizedModels}"""). And at compile-time or build-time having it validated against a database schema, and the compatibility of your types.
- orf 3y ago
  F-strings have been the fastest ever adopted syntax change to Python, and is the overall most popular of the recent post-3.6 additions. That’s Python, but it shares similarities with Java in terms of numerous different ways of formatting strings. They are very, very useful, but lots of people said similar things to you about not getting it. Then… they used them, I guess. \{} is not very verbose either, and the use of generic formatters is a really nice addition.
  - rf15 3y ago
    I'm always happy to have stuff like f-strings in languages. This on the other hand feels much too overladen with separate requirements of safety/etc. which reduces its general usability. Suddenly you don't have to prefix it with "f" / "{}" but "STR." and "\{}", which (unlike f-strings) keeps cluttering your reading space more, something you actually try to improve on with this very feature in other languages. Neither the prefix nor the curly braces are optional for simple terms sadly, unlike in some other languages.
hn_throwaway_99 3y ago
It's nice that they implemented string templates essentially exactly the same way Javascript template literals and tag functions work. They even give an example of using it to create a prepared statement (e.g. DB."SELECT * FROM foo WHERE bar = \{inputParam}") which is exactly what many NodeJS libraries due, e.g. Slonik https://github.com/gajus/slonik https://github.com/gajus/slonik, like sql`SELECT * FROM foo WHERE bar = ${inputParam}`;
- maxloh 3y ago
  Not quite. Dedenting template literal is a pain in the ass, which should have been supported from day one. The TC39 committee actually come up with an additional proposal for that use case.
redditor98654 3y ago
I have read the explanation by various members of the OpenJDK team as to why that syntax was chosen and I still don't understand it. Even Brian's explanation, which otherwise gets right through to me even on more complex topics, did not really clarify it for me. He says choosing ${} would have made all the existing Strings a template if they contain ${} with a valid variable in the same scope, which breaks compatibility. But I don't know what I am missing to not see the breakage. For an existing String literal having a ${...} does not make it into a template that will be processed. You have to explicitly invoke STR. on that to process it as a template. Else if will be just like any other String with no interpolation. STR. is a completely new feature and is illegal in prior versions so I don't see how this breaks compatibility. Even if you had a variable named STR in existing code, it is illegal to do STR."some str literal". I guess it is too late now.

19 points by mfiguiere 3y ago

mfiguiere 3y ago

> Feedback from JDK 21 suggested that String Templates should be finalized for JDK 22.

jiehong 3y ago
Would be nice if they detailed the received feedback.

rf15 3y ago

Even after reading this proposal over the past months over and over in all its iterations, I still don't get it. Is this what many developers want? I fear people will just stick with +concatenation because it's less verbose than this.

LatticeAnimal 3y ago
STR.”what is so bad about \{this}?”
- rf15 3y ago
  `"what is so bad about" + this` uses 4 less characters, and that includes the spaces around the plus.
  - quacker 3y ago
    Except it’s more if I have text following a variable. Try this: STR.”x=\{x} y=\{y} z=\{z}.” Compared to: “x=“ + x + “ y=“ + y + “ z=“ + z + “.” A string template incurs an overhead of 3 characters per variable (“\“, “{“, and “}”) plus the leading “STR.”, which is 4 characters. Concatenation incurs an overhead of 4 non-whitespace characters per variable (`”+` and `+”`), and that’s ignoring whitespace. If you have more than 3-4 variables, string templates are shorter. The concatenation example is less readable as well. Have I included whitespace to exactly match the string template example? It’s a little hard to tell at a glance because I have to distinguish what is code whitespace and what’s included in the string.
  - BenoitP 3y ago
    You may have a point for strings. But this is about guarantees for more convoluted expressions in other languages. If you include validating SQL being injection-free, this is waaay less verbose. Also this is about enabling a _system_ of templating, and potentially letting the IDE treat it as such and warn you at compile-time. Small snippets tend to creep all over a codebase. Some use-case that this enables: * HTML templating React-server-side-style: response.send(HTML_PART."""<div>\{name}</div>"""). Here both the HTML is validated, and the variable is escaped; at compile-time. How do you beat this? * Query-building: businessFilterClause.add(WHERE_VALIDATE."""PRODUCT_MODEL IN \{authorizedModels}"""). And at compile-time or build-time having it validated against a database schema, and the compatibility of your types.
orf 3y ago
F-strings have been the fastest ever adopted syntax change to Python, and is the overall most popular of the recent post-3.6 additions. That’s Python, but it shares similarities with Java in terms of numerous different ways of formatting strings. They are very, very useful, but lots of people said similar things to you about not getting it. Then… they used them, I guess. \{} is not very verbose either, and the use of generic formatters is a really nice addition.
- rf15 3y ago
  I'm always happy to have stuff like f-strings in languages. This on the other hand feels much too overladen with separate requirements of safety/etc. which reduces its general usability. Suddenly you don't have to prefix it with "f" / "{}" but "STR." and "\{}", which (unlike f-strings) keeps cluttering your reading space more, something you actually try to improve on with this very feature in other languages. Neither the prefix nor the curly braces are optional for simple terms sadly, unlike in some other languages.

hn_throwaway_99 3y ago

It's nice that they implemented string templates essentially exactly the same way Javascript template literals and tag functions work. They even give an example of using it to create a prepared statement (e.g. DB."SELECT * FROM foo WHERE bar = \{inputParam}") which is exactly what many NodeJS libraries due, e.g. Slonik https://github.com/gajus/slonik https://github.com/gajus/slonik, like sql`SELECT * FROM foo WHERE bar = ${inputParam}`;

maxloh 3y ago
Not quite. Dedenting template literal is a pain in the ass, which should have been supported from day one. The TC39 committee actually come up with an additional proposal for that use case.

redditor98654 3y ago

I have read the explanation by various members of the OpenJDK team as to why that syntax was chosen and I still don't understand it. Even Brian's explanation, which otherwise gets right through to me even on more complex topics, did not really clarify it for me. He says choosing ${} would have made all the existing Strings a template if they contain ${} with a valid variable in the same scope, which breaks compatibility. But I don't know what I am missing to not see the breakage. For an existing String literal having a ${...} does not make it into a template that will be processed. You have to explicitly invoke STR. on that to process it as a template. Else if will be just like any other String with no interpolation. STR. is a completely new feature and is illegal in prior versions so I don't see how this breaks compatibility. Even if you had a variable named STR in existing code, it is illegal to do STR."some str literal". I guess it is too late now.