5 ms·

Can I call out JavaScript for using backticks for a clean distinction between templated and untemplated strings: - no strange leading character(s) (per C#, VB,

Can I call out JavaScript for using backticks for a clean distinction between templated and untemplated strings: - no strange leading character(s) (per C#, VB, Python, Scala, and now Java) - templated strings are actually distinguished, so don't have to worry about accidentally running into template literals in normal strings (unlike Groovy, Kotlin, Ruby) - the distinguishing mark appears at the end as well as the beginning, for slightly better legibility. - Swift is quite nice in that the backslash is already an escape character for normal strings, so no issue with accidental use, but {} would have been a better choice than () as the former are rarer in normal strings.

pron 3y ago
> no strange leading character(s) (per C#, VB, Python, Scala, and now Java) There are no strange leading characters in Java, either. A template expression is a special case of an instance method call (it's a call to the `process` method on the template processor), and the "leading characters" are the same ones Java already requires for all instance calls. There's nothing strange about them; what is new (and therefore possibly strange) is the use of `"` for the method call instead of a method name followed by `(`. In other words, the new syntax Java added is what follows the dot in the method call to `process`; everything up to and including the dot is normal Java syntax. This is important to emphasise that a template string expression is an a method call that may (although normally shouldn't) even have a side effect. > templated strings are actually distinguished, so don't have to worry about accidentally running into template literals in normal strings Same here. `\{` inside a string remains a syntax error, as it always has been. Also, Java is typed (and the template expression requires a receiver of type StringTemplate.Processor) and there cannot be any ambiguity, and so it's unnecessary to introduce yet another punctuation mark. JS needed further distinguishing syntax because it is untyped.
- somewhereoutth 3y ago
  I understand what you are saying, but on the face of it we have: "my normal string" `my templated string` vs "my normal string" STR."my templated string" probably we can agree which looks cleaner (though I grant, maybe not as 'pluggable')
  - pron 3y ago
    You're talking about string interpolation, and while string interpolation is a special case (and a side effect) of the string templates feature, it's not the goal of the feature. In fact, the feature is designed to help you avoid string interpolation in favour of safer template processors. Ideally, where it matters most, you wouldn't use STR."..." at all, but rather HTML."..." or SQL."....". So the question that's relevant to the core of this feature is, which looks cleaner: SQL."..." or SQL`...` Because this is an actual method call, because Java's type safety and the fact that `\{` is a syntax error in a string means that string and template literals cannot possibly be confused, I think that the former is nicer and clearer for Java programmers and it's only longer by a single character; in fact, I would say that the latter would look very foreign (you could ask whether SQL"..." would be better, but this is an instance method call, and dropping the standard dot, I would argue, would not make things better). You can see it better if you look at the JS examples here (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...), such as: console.log.bind(1, 2)`Hello`; Which, in Java syntax, would be written as: console.log.bind(1, 2)."Hello"; I think it's much less weird for a Java programmer. Also, it's not about "plugging in" other processors. The processor is chosen by the library. If a library offers an HTML processor as part of its API but not a method that takes a string, you simply cannot use STR even if you wanted to. The processor is more a constraint imposed by the API than a plugin you choose to use or not (as the type of the template expression is determined by the processor, and for the interesting processors it is not a string at all but rather a PreparedStatement or some JSON class or HTMLNode). JS offers string interpolation in addition to string templates (or "tagged template strings", as they're called in JS), but we don't offer string interpolation as a Java language feature at all, because it's really dangerous and should be discouraged (certainly not made easier to use than safer templates). But supposed we did want to offer string interpolation in Java, then its syntax would simply be "...". There would be no confusion between a string and a string template even then.

pron 3y ago

> no strange leading character(s) (per C#, VB, Python, Scala, and now Java) There are no strange leading characters in Java, either. A template expression is a special case of an instance method call (it's a call to the `process` method on the template processor), and the "leading characters" are the same ones Java already requires for all instance calls. There's nothing strange about them; what is new (and therefore possibly strange) is the use of `"` for the method call instead of a method name followed by `(`. In other words, the new syntax Java added is what follows the dot in the method call to `process`; everything up to and including the dot is normal Java syntax. This is important to emphasise that a template string expression is an a method call that may (although normally shouldn't) even have a side effect. > templated strings are actually distinguished, so don't have to worry about accidentally running into template literals in normal strings Same here. `\{` inside a string remains a syntax error, as it always has been. Also, Java is typed (and the template expression requires a receiver of type StringTemplate.Processor) and there cannot be any ambiguity, and so it's unnecessary to introduce yet another punctuation mark. JS needed further distinguishing syntax because it is untyped.

somewhereoutth 3y ago
I understand what you are saying, but on the face of it we have: "my normal string" `my templated string` vs "my normal string" STR."my templated string" probably we can agree which looks cleaner (though I grant, maybe not as 'pluggable')
- pron 3y ago
  You're talking about string interpolation, and while string interpolation is a special case (and a side effect) of the string templates feature, it's not the goal of the feature. In fact, the feature is designed to help you avoid string interpolation in favour of safer template processors. Ideally, where it matters most, you wouldn't use STR."..." at all, but rather HTML."..." or SQL."....". So the question that's relevant to the core of this feature is, which looks cleaner: SQL."..." or SQL`...` Because this is an actual method call, because Java's type safety and the fact that `\{` is a syntax error in a string means that string and template literals cannot possibly be confused, I think that the former is nicer and clearer for Java programmers and it's only longer by a single character; in fact, I would say that the latter would look very foreign (you could ask whether SQL"..." would be better, but this is an instance method call, and dropping the standard dot, I would argue, would not make things better). You can see it better if you look at the JS examples here (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...), such as: console.log.bind(1, 2)`Hello`; Which, in Java syntax, would be written as: console.log.bind(1, 2)."Hello"; I think it's much less weird for a Java programmer. Also, it's not about "plugging in" other processors. The processor is chosen by the library. If a library offers an HTML processor as part of its API but not a method that takes a string, you simply cannot use STR even if you wanted to. The processor is more a constraint imposed by the API than a plugin you choose to use or not (as the type of the template expression is determined by the processor, and for the interesting processors it is not a string at all but rather a PreparedStatement or some JSON class or HTMLNode). JS offers string interpolation in addition to string templates (or "tagged template strings", as they're called in JS), but we don't offer string interpolation as a Java language feature at all, because it's really dangerous and should be discouraged (certainly not made easier to use than safer templates). But supposed we did want to offer string interpolation in Java, then its syntax would simply be "...". There would be no confusion between a string and a string template even then.