5 ms·

The comments about this feature are always so tiresome. Please just scroll down and read the "Alternatives" section at the bottom. They're not idiots. They're w

by sitta 3y ago

The comments about this feature are always so tiresome. Please just scroll down and read the "Alternatives" section at the bottom. They're not idiots. They're working within backwards compatibility constraints. They can't just do it like other languages.

rco8786 3y ago
All super weak arguments IMO. Problems that somehow every other language doesn’t have?
- wiseowise 3y ago
  Super weak how? They're quite reasonable and weighed-out.
- marginalia_nu 3y ago
  Other languages are not attempting to be backwards compatible with Java.
  - rco8786 3y ago
    One of the arguments is that existing $ in strings would have to be escaped. Every other language supported $ in strings before interpolation appeared. Not Java specific. Every other language is susceptible to SQL injection style attacks. Not Java specific.
    - marginalia_nu 3y ago
      Few other languages are as committed to backwards compatibility as Java though.
david_allison 3y ago
C# introduced `#nullable enable` to change the behaviour of reference types. Java could do the same to change the behaviour of `$` inside a string (along with a project-level config to make this the default). Let developers opt-in to better syntax, rather than using significantly worse syntax to support legacy code https://learn.microsoft.com/en-us/dotnet/csharp/nullable-migration-strategies https://learn.microsoft.com/en-us/dotnet/csharp/nullable-mig...
- ghusbands 3y ago
  It's moot, anyway, as parser changes are already required by the STR." part. About the only possible defence is that one could use the same lexer, but even that's not true because you can presumably now embed a multi-line string in a single-line string, like so: STR."\{STR.""" \{hey} """}"
vlakreeh 3y ago
Even with their constraints they could have made this nicer, especially around the default formatter. Always requiring an explicit formatter is a classic example of Java being unnecessarily verbose, `\{ ` already wasn't permitted by previous java compilers as it was an unknown escape sequence so we could have nicer templates for the stock formatting like "\{foo} bar".
sergiotapia 3y ago
I think most people read the whole thing. I have. It's still very ugly
troupo 3y ago
Those are extremely weak arguments. Elixir has string interpolation and custom "templates" or whatever they are called without the ugly syntax: ~h"custom one" ~s"custom two" etc.
- ioasuncvinvaer 3y ago
  How are these interpolated?
- jitl 3y ago
  ~x”hi” is basically the same amount of ugly to me as X.”hi”
  - troupo 3y ago
    I find it significantly less jarring than STR."hi"
_old_dude_ 3y ago
You can not use the excuse of the backward compatibility twice. If the string template is prefixed by a processor STR."foo" instead of "foo" then you do not need \{variable} instead of $variable.
- jitl 3y ago
  They want to ensure the new interpolation sequence is a compiler error in non-template strings, so that the incorrect “hi \{name}” is an error instead of silently doing the wrong thing. Using \{ accomplished this because it’s an unknown escape sequence in older Java (so forbidden there), and in new Java will have the more specific error of “yo you forgot the template processor at the start of your template”.
  - _old_dude_ 3y ago
    Yes, you do not get a compile time error, but visually a big STR is front is enough "${variable}" vs STR."${variable}" And editors will use different colors. Using \ or $ is not about backward compatibility but about ergonomics.
- usrusr 3y ago
  You don't want friction on the default path to be too low because that would inevitably increase the occurrence of default path where it must not be used, e.g. cause sql injections. Much easier to accidentally write something that boils down to "\{bobby}" where it should have been SQL."\{bobby}" than STR."\{bobby}" instead of SQL."\{bobby}" (i admit that this argument would work better if STR was typographically more different from the name you'd inevitably use for an SQL statement processor)

by sitta 3y ago

rco8786 3y ago

All super weak arguments IMO. Problems that somehow every other language doesn’t have?

wiseowise 3y ago
Super weak how? They're quite reasonable and weighed-out.
marginalia_nu 3y ago
Other languages are not attempting to be backwards compatible with Java.
- rco8786 3y ago
  One of the arguments is that existing $ in strings would have to be escaped. Every other language supported $ in strings before interpolation appeared. Not Java specific. Every other language is susceptible to SQL injection style attacks. Not Java specific.
  - marginalia_nu 3y ago
    Few other languages are as committed to backwards compatibility as Java though.

david_allison 3y ago

C# introduced `#nullable enable` to change the behaviour of reference types. Java could do the same to change the behaviour of `$` inside a string (along with a project-level config to make this the default). Let developers opt-in to better syntax, rather than using significantly worse syntax to support legacy code https://learn.microsoft.com/en-us/dotnet/csharp/nullable-migration-strategies https://learn.microsoft.com/en-us/dotnet/csharp/nullable-mig...

ghusbands 3y ago
It's moot, anyway, as parser changes are already required by the STR." part. About the only possible defence is that one could use the same lexer, but even that's not true because you can presumably now embed a multi-line string in a single-line string, like so: STR."\{STR.""" \{hey} """}"

vlakreeh 3y ago

Even with their constraints they could have made this nicer, especially around the default formatter. Always requiring an explicit formatter is a classic example of Java being unnecessarily verbose, `\{ ` already wasn't permitted by previous java compilers as it was an unknown escape sequence so we could have nicer templates for the stock formatting like "\{foo} bar".

sergiotapia 3y ago

I think most people read the whole thing. I have. It's still very ugly

troupo 3y ago

Those are extremely weak arguments. Elixir has string interpolation and custom "templates" or whatever they are called without the ugly syntax: ~h"custom one" ~s"custom two" etc.

ioasuncvinvaer 3y ago
How are these interpolated?
jitl 3y ago
~x”hi” is basically the same amount of ugly to me as X.”hi”
- troupo 3y ago
  I find it significantly less jarring than STR."hi"

_old_dude_ 3y ago

You can not use the excuse of the backward compatibility twice. If the string template is prefixed by a processor STR."foo" instead of "foo" then you do not need \{variable} instead of $variable.

jitl 3y ago
They want to ensure the new interpolation sequence is a compiler error in non-template strings, so that the incorrect “hi \{name}” is an error instead of silently doing the wrong thing. Using \{ accomplished this because it’s an unknown escape sequence in older Java (so forbidden there), and in new Java will have the more specific error of “yo you forgot the template processor at the start of your template”.
- _old_dude_ 3y ago
  Yes, you do not get a compile time error, but visually a big STR is front is enough "${variable}" vs STR."${variable}" And editors will use different colors. Using \ or $ is not about backward compatibility but about ergonomics.
usrusr 3y ago
You don't want friction on the default path to be too low because that would inevitably increase the occurrence of default path where it must not be used, e.g. cause sql injections. Much easier to accidentally write something that boils down to "\{bobby}" where it should have been SQL."\{bobby}" than STR."\{bobby}" instead of SQL."\{bobby}" (i admit that this argument would work better if STR was typographically more different from the name you'd inevitably use for an SQL statement processor)