3 ms·
It is a source of so many security issues. Retracting a JEP that does not have broad support is the sane thing to do. There are enough languages with features t
by bjoli 2y ago
It is a source of so many security issues. Retracting a JEP that does not have broad support is the sane thing to do. There are enough languages with features that have not had every kink solved before standardisation. It is always a source of pain.
- jbverschoor 2y agoHow does it differ from just concatenating?
- kaba0 2y agoYou don’t want to just concatenate Little Bobby tables.
- bjoli 2y agoBoth are sources of vulnerabilities, of course. But I believe a nice string interpolation implementation can allow for validation (like the java one did). That means that whenever you are working with texts, a library can enforce constraints that in the case of concatenation would have meant a domain specific API for each library. My message isn't pick one over the other it is that whatever you pick, make sure it isn't a hack that people will regret using.
- neonsunset 2y agoDefinitely possible: https://learn.microsoft.com/en-us/ef/core/querying/sql-queries#composing-with-linq https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...
- bjoli 2y agoExactly. A specific API. Foe SQL that is good, but for smaller things a proper interpolation thing is great.
- neonsunset 2y agoI was just showcasing that you can have both - there is regular string interpolation and there are APIs to accept interpolated expressions and then handle them arbitrarily (you can't pass a regular string produced by an interpolation to FromSql(expr), only to FromSqlRaw which makes IDE yell at you to make sure you know what you are doing), without even having to materialize the string if that isn't the intention. Java ended up having neither which seems rather extreme.