It’s great to see they’re putting some effort into some really powerful string templates. I like the versitility in the approach they’ve gone with. Just a couple things stood out to me.
The problem with interpolation is that it’s dangerous as a global feature, because it doesn’t allow for validation or sanitization when constructing the final string. This exposes it, for example, to SQL or JavaScript injections.
Actually no, not having interpolation just makes it more verbose to create those vulnerabilities. Also, SQL injections aren’t solved by validation and sanitization (well I guess in theory they can be if you’re aggressive enough), they’re solved with parameterized queries. These issues exist regardless, but lack of interpolation makes things significantly more verbose for the 99.9% of other cases where you aren’t sending commands to a server. The cause of these vulnerabilities is inexperienced (or sometimes careless) developers trying to concat all their queries together, and this will help mitigate that but is unlikely to solve it.
The problem with interpolation seems to me to be a purely cultural thing. Pointing fingers at arbitrary reasons isn’t really helping the argument against it, and it’s completely valid to say “it just didn’t feel like it belonged in Java until now, and we wanted to make sure we got it right”, which I would much more readily believe.
There has been a lot of discussion around the choice of the expression format. Due to the existence of many libraries using $, # or {} as expression delimiters, the choice was for a format that is not valid outside String Templates
This seems backwards to me. Wouldn’t you want them to feel as familiar as possible to users of these libraries and make migration easy for many users? It’s not like the syntax for string templates would compile before anyway (unless there’s something I’m missing) since they all require the template processor to be specified.
Skimming through the rest of the features, it seems like there’s a lot of usability improvements, which is awesome to see!
They all require the template processor to be specified, but I’m likely to convert hundreds or thousands of lines of existing string concatenation to templates in one of my projects and I really appreciate that the only \{ that show up will be the ones I create.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
It’s great to see they’re putting some effort into some really powerful string templates. I like the versitility in the approach they’ve gone with. Just a couple things stood out to me.
Actually no, not having interpolation just makes it more verbose to create those vulnerabilities. Also, SQL injections aren’t solved by validation and sanitization (well I guess in theory they can be if you’re aggressive enough), they’re solved with parameterized queries. These issues exist regardless, but lack of interpolation makes things significantly more verbose for the 99.9% of other cases where you aren’t sending commands to a server. The cause of these vulnerabilities is inexperienced (or sometimes careless) developers trying to concat all their queries together, and this will help mitigate that but is unlikely to solve it.
The problem with interpolation seems to me to be a purely cultural thing. Pointing fingers at arbitrary reasons isn’t really helping the argument against it, and it’s completely valid to say “it just didn’t feel like it belonged in Java until now, and we wanted to make sure we got it right”, which I would much more readily believe.
This seems backwards to me. Wouldn’t you want them to feel as familiar as possible to users of these libraries and make migration easy for many users? It’s not like the syntax for string templates would compile before anyway (unless there’s something I’m missing) since they all require the template processor to be specified.
Skimming through the rest of the features, it seems like there’s a lot of usability improvements, which is awesome to see!
They all require the template processor to be specified, but I’m likely to convert hundreds or thousands of lines of existing string concatenation to templates in one of my projects and I really appreciate that the only \{ that show up will be the ones I create.