3 ms·

> Would it hurt them to use ${x} instead of \{x}? There are multiple reasons to prefer \: 1. In Java, \ is already the character that signifies that what foll

by pron 3y ago

> Would it hurt them to use ${x} instead of \{x}? There are multiple reasons to prefer \: 1. In Java, \ is already the character that signifies that what follows has a special meaning, while the use of $ is foreign (to the language). 2. `\{` is a syntax error inside string literals, which means it appears nowhere inside string literals, while $ is fairly common; it would also mean that $ will need to be written differently inside string and string template literals. 3. The use of $ for interpolation is common in Java templating libraries, and it's preferable for the language to use something different (in JS, where $ is used by the language, templating libraries also use something else, like `{{`). See https://mail.openjdk.org/pipermail/amber-spec-experts/2023-April/003827.html https://mail.openjdk.org/pipermail/amber-spec-experts/2023-A... > or something to that effect (and similar for sql.identifier etc). You can already do that if you want: X."blah \{sqlString(x)} blah"; But this feature is being added to Java to solve the pretty serious problem of code injection, and so the more important thing is the selection of the processor, which ensures safety, i.e. an HTML API will offer an HTML processor and will not accept strings. Remember, string templates are most useful when what they produce is not a string, but rather construct a specific API entity.

coldtea 3y ago
>But this feature is being added to Java to solve the pretty serious problem of code injection My take is that it will do little for code injection. Most programmers will use STR/FMT, and unless they offer an HTML or an SQL processor in the stdlib, they wont be used. >Remember, string templates are most useful when what they produce is not a string, but rather construct a specific API entity Sure, but the processor can do little short of implementing full parsing to understand the context of say HTML or SQL, right?
- pron 3y ago
  > Most programmers will use STR/FMT, and unless they offer an HTML or an SQL processor in the stdlib, they wont be used. New processors obviously can't be used unless they're offered by a library, but when they are, they must be used. The libraries simply won't offer an API based on strings (and, therefore, interpolated strings), or if they already do, they will be able to deprecate them. If an HTML library has no API that takes strings, then STR/FMT simply can't be used. The library can enforce the safety of its API. > Sure, but the processor can do little short of implementing full parsing to understand the context of say HTML or SQL, right? Yes, that's the point. An HTML library will offer an HTML processor, and similarly for a JSON or SQL library. I'm not apprised of the exact status, but I believe that the team specifying JDBC is looking into offering a SQL processor as part of JDBC.

by pron 3y ago

coldtea 3y ago

>But this feature is being added to Java to solve the pretty serious problem of code injection My take is that it will do little for code injection. Most programmers will use STR/FMT, and unless they offer an HTML or an SQL processor in the stdlib, they wont be used. >Remember, string templates are most useful when what they produce is not a string, but rather construct a specific API entity Sure, but the processor can do little short of implementing full parsing to understand the context of say HTML or SQL, right?

pron 3y ago
> Most programmers will use STR/FMT, and unless they offer an HTML or an SQL processor in the stdlib, they wont be used. New processors obviously can't be used unless they're offered by a library, but when they are, they must be used. The libraries simply won't offer an API based on strings (and, therefore, interpolated strings), or if they already do, they will be able to deprecate them. If an HTML library has no API that takes strings, then STR/FMT simply can't be used. The library can enforce the safety of its API. > Sure, but the processor can do little short of implementing full parsing to understand the context of say HTML or SQL, right? Yes, that's the point. An HTML library will offer an HTML processor, and similarly for a JSON or SQL library. I'm not apprised of the exact status, but I believe that the team specifying JDBC is looking into offering a SQL processor as part of JDBC.