Hi Tagir,
while subclassing is handy, I think it actively works against the goal
of trying to make string handling any safer.
Let’s consider the case of a /new/ API, that wants to do things the
/right/ way. This API will provide a StringTemplate-accepting factory.
But if clients can supply a value using |"foo" + bar|, then we’re back
to where we started: the new API is no safer than a String-accepting
factory.
Note: there is a big difference between passing |"foo" + bar| and
|"foo\{bar}"|. In the former, the library only gets a string. It has no
way to distinguish between which values were user-provided, and which
ones were constant. In the latter, the string template has a value. The
library might need to analyze that value more carefully as it might come
from outside.
The main value of string templates is to allow clients to capture what
/can change/ and separate it from what /cannot/ change. Attacks
typically lurk in the variable part. But eager interpolation (e.g.
string +) destroys this separation.
I think that most of the APIs will still provide String overload.
E.g., for preparing an SQL statement, it's a perfectly reasonable
scenario to have a constant string as the input. So
prepareStatement(String) will stay along with
prepareStatement(StringTemplate). And people will still be able to use
concatenation. I don't think that the absence of String <:
StringTemplate relation will protect anybody from using the
concatenation. On the other hand, if String actually implements
StringTemplate, it will be a very simple static analysis rule to warn
if the concatenation occurs in this context. If the expected type for
concatenation is StringTemplate, then something is definitely wrong.
Without 'String implements StringTemplate', one will not be able to
write a concatenation directly in StringTemplate context. Instead,
String-accepting overload will be used, and the expected type will be
String, so static analyzer will have to guess whether it's dangerous
to use the concatenation here. In short, I think that it's actually an
advantage: we have an additional hint here that concatenation is
undesired. Even compilation warning could be possible to implement.
So, I don't see these points as real disadvantages. I definitely like
this approach much more than adding any kind of implicit conversion or
another literal syntax, which would complicate the specification much
more.
I don’t buy that, since there’s already String-accepting API in the
wild, then we can never be safer than that. String-accepting variant can
be deprecated, if needs be.
Maurizio
