3 ms·

Sadly, true. Why is the template processor named `STR`, why not `f"String"`, like Python? On top of the ugly `STR.` prefix, this dreaded `\` character infuriate

Sadly, true. Why is the template processor named `STR`, why not `f"String"`, like Python? On top of the ugly `STR.` prefix, this dreaded `\` character infuriates me more. Kotlin and Groovy have the nicest implementation by far because it doesn't require any prefixes. I understand Java can't suddenly do that because it needs to be backward-compatible. I can't get over the ugly `\{someVar}`. It will be easily confused as the `{` character is being escaped, rather than a template. `${someVar}` was a much better option.

dariusj18 3y ago
So weird that of all the choices they decide to use something used as an escape character.
turboponyy 3y ago
The backslash is unsightly, I agree. Codifying template expression evaluators as a core part of the language, however, is a rational choice. Java is surprisingly foresightful in this regard - it means idioms in the language itself can guide people to getting the common use case of interpolating stuff correct. "STR" for the most prevalent case is perhaps a bit verbose, but at least it's explicit.
prng2021 3y ago
Yea, I’m actually a big fan of Java but my immediate reaction to the syntax here was wtf.
masklinn 3y ago
> Sadly, true. Why is the template processor named `STR`, why not `f"String"`, like Python? It looks like the prefix is pluggable so you can use different template processors, STR is just the default: > STR is a template processor defined in the Java Platform. It performs string interpolation by replacing each embedded expression in the template with the (stringified) value of that expression. > FMT is another template processor defined in the Java Platform. FMT is like STR in that it performs interpolation, but it also interprets format specifiers which appear to the left of embedded expressions. > Developers can easily create template processors for use in template expressions. This is similar to Javascript's `tagged templates`: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe.... Python's f-strings are very much lacking that. Although I do agree that the syntax, both of the prefix and the interpolation symbol, is awful.
pron 3y ago
> the ugly `STR.` prefix STR is not a prefix but simply the name of the variable referencing the receiver (template processor) of the call, i.e. you can do: var x = STR; x."...."; In Java, making instance method calls requires a receiver to the left of a `.`. Even though template processing has special syntax, it is still a call to an instance method defined by a normal Java interface, and so, as always, requires a receiver. The new syntax here is what's to the right of the `.`; what's to the left is old syntax. > It will be easily confused as the `{` character is being escaped It is being escaped, and so reading it as being escaped is the correct and intended understanding. Just like `\n` or `\t`, `\{` means that the next character has a special meaning, as it always does in Java. There was no need to introduce yet another escape sequence; the old one works just fine.
- masklinn 3y ago
  > The new syntax here is what's to the right of the `.`; what's to the left is old syntax. Absolutely nothing precluded extending the new syntax to swallowing / obviating the `.`.
  - pron 3y ago
    True, but nothing necessitated it, either. New features are tested by users for a while (and this one has even been a preview feature in a released JDK for some time), and the people who have actually used the feature didn't report that typing `.` was a problem to them. If further experience shows otherwise, then we could allow dropping the dot. In other words, security vulnerabilities due to string manipulation are a real and pretty serious problem that this feature aims to solve (or, at least alleviate). If the dot character also proves to be a real problem, which it hasn't yet, then that could be solved later.
- mhosain 3y ago
  > STR is not a prefix but simply the name of the variable referencing the receiver That is THE problem. You can use StringBuilder more easily than this ugly thing. When you write code in IDE (I hope so), writing `.append()` is actually easier than this `\{}` dreadful thing. > It is being escaped, and so reading it as being escaped is the correct and intended understanding. Just like `\n` or `\t`, `\{` means that the next character has a special meaning, as it always does in Java. There was no need to introduce yet another escape sequence; the old one works just fine. But what about the `}` after the expression? Who/what is escaping that? It should make it clear that this is a special syntax that does some special things. `\` is sort of universal escape character. Putting it in here feels wrong. Again, that's me (along with some other), and you definitely can disagree.
wiseowise 3y ago
There's literally section called `The STR template processor`.
- mhosain 3y ago
  Yeah, but than what was the point? We could've continue to use existing methods. The goal was getting something clean and friendly. Look at Python for example. Any similar solution would have made it both non-breaking (codes won't compile with unsupported version) and clean.

dariusj18 3y ago

So weird that of all the choices they decide to use something used as an escape character.

turboponyy 3y ago

The backslash is unsightly, I agree. Codifying template expression evaluators as a core part of the language, however, is a rational choice. Java is surprisingly foresightful in this regard - it means idioms in the language itself can guide people to getting the common use case of interpolating stuff correct. "STR" for the most prevalent case is perhaps a bit verbose, but at least it's explicit.

prng2021 3y ago

Yea, I’m actually a big fan of Java but my immediate reaction to the syntax here was wtf.

masklinn 3y ago

> Sadly, true. Why is the template processor named `STR`, why not `f"String"`, like Python? It looks like the prefix is pluggable so you can use different template processors, STR is just the default: > STR is a template processor defined in the Java Platform. It performs string interpolation by replacing each embedded expression in the template with the (stringified) value of that expression. > FMT is another template processor defined in the Java Platform. FMT is like STR in that it performs interpolation, but it also interprets format specifiers which appear to the left of embedded expressions. > Developers can easily create template processors for use in template expressions. This is similar to Javascript's `tagged templates`: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe.... Python's f-strings are very much lacking that. Although I do agree that the syntax, both of the prefix and the interpolation symbol, is awful.

pron 3y ago

> the ugly `STR.` prefix STR is not a prefix but simply the name of the variable referencing the receiver (template processor) of the call, i.e. you can do: var x = STR; x."...."; In Java, making instance method calls requires a receiver to the left of a `.`. Even though template processing has special syntax, it is still a call to an instance method defined by a normal Java interface, and so, as always, requires a receiver. The new syntax here is what's to the right of the `.`; what's to the left is old syntax. > It will be easily confused as the `{` character is being escaped It is being escaped, and so reading it as being escaped is the correct and intended understanding. Just like `\n` or `\t`, `\{` means that the next character has a special meaning, as it always does in Java. There was no need to introduce yet another escape sequence; the old one works just fine.

masklinn 3y ago
> The new syntax here is what's to the right of the `.`; what's to the left is old syntax. Absolutely nothing precluded extending the new syntax to swallowing / obviating the `.`.
- pron 3y ago
  True, but nothing necessitated it, either. New features are tested by users for a while (and this one has even been a preview feature in a released JDK for some time), and the people who have actually used the feature didn't report that typing `.` was a problem to them. If further experience shows otherwise, then we could allow dropping the dot. In other words, security vulnerabilities due to string manipulation are a real and pretty serious problem that this feature aims to solve (or, at least alleviate). If the dot character also proves to be a real problem, which it hasn't yet, then that could be solved later.
mhosain 3y ago
> STR is not a prefix but simply the name of the variable referencing the receiver That is THE problem. You can use StringBuilder more easily than this ugly thing. When you write code in IDE (I hope so), writing `.append()` is actually easier than this `\{}` dreadful thing. > It is being escaped, and so reading it as being escaped is the correct and intended understanding. Just like `\n` or `\t`, `\{` means that the next character has a special meaning, as it always does in Java. There was no need to introduce yet another escape sequence; the old one works just fine. But what about the `}` after the expression? Who/what is escaping that? It should make it clear that this is a special syntax that does some special things. `\` is sort of universal escape character. Putting it in here feels wrong. Again, that's me (along with some other), and you definitely can disagree.

wiseowise 3y ago

There's literally section called `The STR template processor`.

mhosain 3y ago
Yeah, but than what was the point? We could've continue to use existing methods. The goal was getting something clean and friendly. Look at Python for example. Any similar solution would have made it both non-breaking (codes won't compile with unsupported version) and clean.