3 ms·

I wasn't able to tell from this document, IMO since they are focused on safety as a reason for their templates approach, they should include some defaults for c

I wasn't able to tell from this document, IMO since they are focused on safety as a reason for their templates approach, they should include some defaults for common scenarios if they'd liked this to gain wider usage. For example that QueryBuilder they used for SQL would be useful. Too often I see experienced developers using string interpolation for SQL and not realising it's open to injection. I feel the document's intentions are good but because the implementation looks so verbose they should make it as frictionless as possible to gain wider adoption. Else all that's going to happen is people will only ever use STR.

exabrial 3y ago
I think the whole thing is pretty useless, but I guess the point is that with your own template format you could write a string template format that fully escapes sql variables, for instance. Yes, we already have that problem solved with JPQL or even just plain prepared statement but that’s never stopped anyone… And yes, you could also write a message formatter the current Java that does that…
layer8 3y ago
I’d go further and say they shouldn’t provide STR. The difference in syntactic (in)convenience between "..." + foo + "..." + bar + "..." and STR."...\{foo}...\{bar}..." is negligible. And then the syntax FOO."..." would at least imply that some special processing is going on.
- pron 3y ago
  Except then it would still be absolutely trivial for people to write their own string-interpolating template processors, which they would definitely do, and so we figured we might as well offer a standard one (that also offers better performance than hand-rolled ones). It is difficult to find the right balance between educating people to do "the right thing" as we see it and rolling with the recognition that they not always will. I wish we could say there's some formula we apply, but we need to exercise such judgment with lots of features and it's never a trivial decision. In this case we figured that if we make the thing people will want to do anyway no easier than the "right thing", that's probably as good as we can do, all things considered.
mike_hearn 3y ago
The nice thing about this design is that the correct thing is also easier than the incorrect thing: var q = DB."SELECT foo FROM bar WHERE a = \{b}"; // PreparedStatement? var results = conn.execute(q); // ResultSet is shorter and easier to write than the non-safe alternative. That said, I wonder how often people are writing queries out by hand like that these days vs using ORMs or jOOQ.

exabrial 3y ago

I think the whole thing is pretty useless, but I guess the point is that with your own template format you could write a string template format that fully escapes sql variables, for instance. Yes, we already have that problem solved with JPQL or even just plain prepared statement but that’s never stopped anyone… And yes, you could also write a message formatter the current Java that does that…

layer8 3y ago

I’d go further and say they shouldn’t provide STR. The difference in syntactic (in)convenience between "..." + foo + "..." + bar + "..." and STR."...\{foo}...\{bar}..." is negligible. And then the syntax FOO."..." would at least imply that some special processing is going on.

pron 3y ago
Except then it would still be absolutely trivial for people to write their own string-interpolating template processors, which they would definitely do, and so we figured we might as well offer a standard one (that also offers better performance than hand-rolled ones). It is difficult to find the right balance between educating people to do "the right thing" as we see it and rolling with the recognition that they not always will. I wish we could say there's some formula we apply, but we need to exercise such judgment with lots of features and it's never a trivial decision. In this case we figured that if we make the thing people will want to do anyway no easier than the "right thing", that's probably as good as we can do, all things considered.

mike_hearn 3y ago

The nice thing about this design is that the correct thing is also easier than the incorrect thing: var q = DB."SELECT foo FROM bar WHERE a = \{b}"; // PreparedStatement? var results = conn.execute(q); // ResultSet is shorter and easier to write than the non-safe alternative. That said, I wonder how often people are writing queries out by hand like that these days vs using ORMs or jOOQ.