3 ms·

> 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 th

> 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.

pron 3y ago
> 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. How long have you been using string templates? If you've had a bad experience, please report it to the amber-dev list. If it's speculation, I suggest you actually try the feature for a while. Also, I think you may have misunderstood what this feature actually does (please read the JEP). StringBuilder produces strings, but string templates are most powerful when you're not producing strings (and `append` does enforce sanitisation/escaping). This feature is not string interpolation (although it could also be used for string interpolation as a special case), and its function is completely different from that of StringBuilder. StringBuilder simply cannot do what this feature does regardless of your thoughts about the syntax, which may or may not be formed after actual experience. > But what about the `}` after the expression? Who/what is escaping that? You don't need to. `\` in Java means that the next character triggers some special interpretation, and `\{` means that the interpretation mode continues until the `}`. The closing curly bracket should require no more of a special treatment than the characters inside the curly brackets. > Putting it in here feels wrong. When you say "feels wrong" do you mean you've tried the feature for a while and ran into problems or that you simply fear that you might?
- mhosain 3y ago
  > Also, I think you may have misunderstood what this feature... No, I am aware of the differences between StringBuilder and string templating. One of the most common usage is concatenation (e.g. toString() methods). Sometimes it's cleaner to use StringBuilder instead of + operator to do that. And templating will be mostly used for concatenation. All I am saying is, it could be simpler. I read the full JEP before my first comment. I frequently do Python and did little bit of Kotlin before. I guess that's where all this is coming from.
  - pron 3y ago
    > And templating will be mostly used for concatenation. Whether it will or won't, interpolation is not the reason for the feature, so clearly that's not the use case that should be prioritised, especially as it's been recognised as an exceptionally dangerous use-case. The starting point that we must in no way make string interpolation, which is known to be dangerous, any easier than using safer template processors. This feature was created (among some other reasons) to solve the severe security problems created by string manipulation, not to make string concatenation -- which is already pretty easy -- easier. As the JEP explains, after a lot of thought the decision was not to offer string interpolation as a language feature and go for string templates instead. Saying that the feature doesn't accomplish well the thing it explicitly doesn't try to accomplish is really not saying much about the potential of this feature. Making string interpolation as easy as it could possibly be was not only not a goal of this feature, but the very thing it was designed to avoid given how dangerous that is. On the other hand, consider that you can now safely embed HTML templates in Java code. > I frequently do Python and did little bit of Kotlin before. I guess that's where all this is coming from. In this case, as in many others, we studied what many other languages did, incorporated what's been learnt about code injection vulnerabilities, and did what we believe to be a marked improvement over other languages' features, at least as appropriate for Java's users. You may disagree, but a lot of thought has gone into the design by some of the world's most accomplished language designers as well as user testing, and so I don't think speculation trumps that. If further experience shows that we got it wrong, it can be fixed.

pron 3y ago

> 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. How long have you been using string templates? If you've had a bad experience, please report it to the amber-dev list. If it's speculation, I suggest you actually try the feature for a while. Also, I think you may have misunderstood what this feature actually does (please read the JEP). StringBuilder produces strings, but string templates are most powerful when you're not producing strings (and `append` does enforce sanitisation/escaping). This feature is not string interpolation (although it could also be used for string interpolation as a special case), and its function is completely different from that of StringBuilder. StringBuilder simply cannot do what this feature does regardless of your thoughts about the syntax, which may or may not be formed after actual experience. > But what about the `}` after the expression? Who/what is escaping that? You don't need to. `\` in Java means that the next character triggers some special interpretation, and `\{` means that the interpretation mode continues until the `}`. The closing curly bracket should require no more of a special treatment than the characters inside the curly brackets. > Putting it in here feels wrong. When you say "feels wrong" do you mean you've tried the feature for a while and ran into problems or that you simply fear that you might?

mhosain 3y ago
> Also, I think you may have misunderstood what this feature... No, I am aware of the differences between StringBuilder and string templating. One of the most common usage is concatenation (e.g. toString() methods). Sometimes it's cleaner to use StringBuilder instead of + operator to do that. And templating will be mostly used for concatenation. All I am saying is, it could be simpler. I read the full JEP before my first comment. I frequently do Python and did little bit of Kotlin before. I guess that's where all this is coming from.
- pron 3y ago
  > And templating will be mostly used for concatenation. Whether it will or won't, interpolation is not the reason for the feature, so clearly that's not the use case that should be prioritised, especially as it's been recognised as an exceptionally dangerous use-case. The starting point that we must in no way make string interpolation, which is known to be dangerous, any easier than using safer template processors. This feature was created (among some other reasons) to solve the severe security problems created by string manipulation, not to make string concatenation -- which is already pretty easy -- easier. As the JEP explains, after a lot of thought the decision was not to offer string interpolation as a language feature and go for string templates instead. Saying that the feature doesn't accomplish well the thing it explicitly doesn't try to accomplish is really not saying much about the potential of this feature. Making string interpolation as easy as it could possibly be was not only not a goal of this feature, but the very thing it was designed to avoid given how dangerous that is. On the other hand, consider that you can now safely embed HTML templates in Java code. > I frequently do Python and did little bit of Kotlin before. I guess that's where all this is coming from. In this case, as in many others, we studied what many other languages did, incorporated what's been learnt about code injection vulnerabilities, and did what we believe to be a marked improvement over other languages' features, at least as appropriate for Java's users. You may disagree, but a lot of thought has gone into the design by some of the world's most accomplished language designers as well as user testing, and so I don't think speculation trumps that. If further experience shows that we got it wrong, it can be fixed.