<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <div class="markdown-here-wrapper" data-md-url="" style="">
      <p style="margin: 0px 0px 1.2em !important;">Hi Tagir,<br>
        while subclassing is handy, I think it actively works against
        the goal of trying to make string handling any safer.</p>
      <p style="margin: 0px 0px 1.2em !important;">Let’s consider the
        case of a <em>new</em> API, that wants to do things the <em>right</em>
        way. This API will provide a StringTemplate-accepting factory.</p>
      <p style="margin: 0px 0px 1.2em !important;">But if clients can
        supply a value using <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">"foo" + bar</code>,
        then we’re back to where we started: the new API is no safer
        than a String-accepting factory.</p>
      <p style="margin: 0px 0px 1.2em !important;">Note: there is a big
        difference between passing <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">"foo" + bar</code>
        and <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">"foo\{bar}"</code>.
        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.</p>
      <p style="margin: 0px 0px 1.2em !important;">The main value of
        string templates is to allow clients to capture what <em>can
          change</em> and separate it from what <em>cannot</em> change.
        Attacks typically lurk in the variable part. But eager
        interpolation (e.g. string +) destroys this separation.</p>
      <p style="margin: 0px 0px 1.2em !important;"></p>
      <div class="markdown-here-exclude">
        <p></p>
        <blockquote type="cite" cite="mid:CAE+3fjYP3xo4BPomSuvoG-whTQCNTKs6tK3SOUCuHT5YvZ0iWw@mail.gmail.com">
          <div dir="ltr">
            <div class="gmail_quote">
              <div>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.</div>
              <div><br>
              </div>
              <div>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.</div>
            </div>
          </div>
        </blockquote>
        <p></p>
      </div>
      <p style="margin: 0px 0px 1.2em !important;"></p>
      <p style="margin: 0px 0px 1.2em !important;">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.</p>
      <p style="margin: 0px 0px 1.2em !important;">Maurizio</p>
      <div title="MDH:PHA+SGkgVGFnaXIsPGJyPndoaWxlIHN1YmNsYXNzaW5nIGlzIGhhbmR5LCBJIHRoaW5rIGl0IGFj
dGl2ZWx5IHdvcmtzIGFnYWluc3QgdGhlIGdvYWwgb2YgdHJ5aW5nIHRvIG1ha2Ugc3RyaW5nIGhh
bmRsaW5nIGFueSBzYWZlci48L3A+PHA+TGV0J3MgY29uc2lkZXIgdGhlIGNhc2Ugb2YgYSBfbmV3
XyBBUEksIHRoYXQgd2FudHMgdG8gZG8gdGhpbmdzIHRoZSBfcmlnaHRfIHdheS4gVGhpcyBBUEkg
d2lsbCBwcm92aWRlIGEgU3RyaW5nVGVtcGxhdGUtYWNjZXB0aW5nIGZhY3RvcnkuPC9wPjxwPkJ1
dCBpZiBjbGllbnRzIGNhbiBzdXBwbHkgYSB2YWx1ZSB1c2luZyBgImZvbyIgKyBiYXJgLCB0aGVu
IHdlJ3JlIGJhY2sgdG8gd2hlcmUgd2Ugc3RhcnRlZDogdGhlIG5ldyBBUEkgaXMgbm8gc2FmZXIg
dGhhbiBhIFN0cmluZy1hY2NlcHRpbmcgZmFjdG9yeS48L3A+PHA+Tm90ZTogdGhlcmUgaXMgYSBi
aWcgZGlmZmVyZW5jZSBiZXR3ZWVuIHBhc3NpbmcgYCJmb28iICsgYmFyYCBhbmQgYCJmb29ce2Jh
cn0iYC4gSW4gdGhlIGZvcm1lciwgdGhlIGxpYnJhcnkgb25seSBnZXRzIGEgc3RyaW5nLiBJdCBo
YXMgbm8gd2F5IHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gd2hpY2ggdmFsdWVzIHdlcmUgdXNlci1w
cm92aWRlZCwgYW5kIHdoaWNoIG9uZXMgd2VyZSBjb25zdGFudC4gSW4gdGhlIGxhdHRlciwgdGhl
IHN0cmluZyB0ZW1wbGF0ZSBoYXMgYSB2YWx1ZS4gVGhlIGxpYnJhcnkgbWlnaHQgbmVlZCB0byBh
bmFseXplIHRoYXQgdmFsdWUgbW9yZSBjYXJlZnVsbHkgYXMgaXQgbWlnaHQgY29tZSBmcm9tIG91
dHNpZGUuPC9wPjxwPlRoZSBtYWluIHZhbHVlIG9mIHN0cmluZyB0ZW1wbGF0ZXMgaXMgdG8gYWxs
b3cgY2xpZW50cyB0byBjYXB0dXJlIHdoYXQgX2NhbiBjaGFuZ2VfIGFuZCBzZXBhcmF0ZSBpdCBm
cm9tIHdoYXQgX2Nhbm5vdF8gY2hhbmdlLiBBdHRhY2tzIHR5cGljYWxseSBsdXJrIGluIHRoZSB2
YXJpYWJsZSBwYXJ0LiBCdXQgZWFnZXIgaW50ZXJwb2xhdGlvbiAoZS5nLiBzdHJpbmcgKykgZGVz
dHJveXMgdGhpcyBzZXBhcmF0aW9uLjwvcD48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0
ZT0ibWlkOkNBRSszZmpZUDN4bzRCUG9tU3V2b0ctd2hUUUNOVEtzNnRLM1NPVUN1SFQ1WXZaMGlX
d0BtYWlsLmdtYWlsLmNvbSI+PGRpdiBkaXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUi
PjxkaXY+SSB0aGluayB0aGF0IG1vc3Qgb2YgdGhlIEFQSXMgd2lsbCBzdGlsbCBwcm92aWRlIFN0
cmluZyBvdmVybG9hZC4gRS5nLiwgZm9yIHByZXBhcmluZyBhbiBTUUwgc3RhdGVtZW50LCBpdCdz
IGEgcGVyZmVjdGx5IHJlYXNvbmFibGUgc2NlbmFyaW8mbmJzcDt0byBoYXZlIGEgY29uc3RhbnQg
c3RyaW5nIGFzIHRoZSBpbnB1dC4gU28gcHJlcGFyZVN0YXRlbWVudChTdHJpbmcpIHdpbGwgc3Rh
eSBhbG9uZyB3aXRoIHByZXBhcmVTdGF0ZW1lbnQoU3RyaW5nVGVtcGxhdGUpLiBBbmQgcGVvcGxl
IHdpbGwgc3RpbGwgYmUgYWJsZSB0byB1c2UgY29uY2F0ZW5hdGlvbi4gSSBkb24ndCB0aGluayB0
aGF0IHRoZSBhYnNlbmNlIG9mIFN0cmluZyAmbHQ7OiBTdHJpbmdUZW1wbGF0ZSByZWxhdGlvbiB3
aWxsIHByb3RlY3QgYW55Ym9keSBmcm9tIHVzaW5nIHRoZSBjb25jYXRlbmF0aW9uLiBPbiB0aGUg
b3RoZXIgaGFuZCwgaWYgU3RyaW5nIGFjdHVhbGx5IGltcGxlbWVudHMgU3RyaW5nVGVtcGxhdGUs
IGl0IHdpbGwgYmUgYSB2ZXJ5IHNpbXBsZSBzdGF0aWMgYW5hbHlzaXMgcnVsZSB0byB3YXJuIGlm
IHRoZSBjb25jYXRlbmF0aW9uIG9jY3VycyBpbiB0aGlzIGNvbnRleHQuIElmIHRoZSBleHBlY3Rl
ZCB0eXBlIGZvciBjb25jYXRlbmF0aW9uIGlzIFN0cmluZ1RlbXBsYXRlLCB0aGVuIHNvbWV0aGlu
ZyBpcyBkZWZpbml0ZWx5IHdyb25nLiBXaXRob3V0ICdTdHJpbmcgaW1wbGVtZW50cyBTdHJpbmdU
ZW1wbGF0ZScsIG9uZSB3aWxsIG5vdCBiZSBhYmxlIHRvIHdyaXRlIGEgY29uY2F0ZW5hdGlvbiBk
aXJlY3RseSBpbiBTdHJpbmdUZW1wbGF0ZSBjb250ZXh0LiBJbnN0ZWFkLCBTdHJpbmctYWNjZXB0
aW5nIG92ZXJsb2FkIHdpbGwgYmUgdXNlZCwgYW5kIHRoZSBleHBlY3RlZCB0eXBlIHdpbGwgYmUg
U3RyaW5nLCBzbyBzdGF0aWMgYW5hbHl6ZXIgd2lsbCBoYXZlIHRvIGd1ZXNzIHdoZXRoZXIgaXQn
cyBkYW5nZXJvdXMgdG8gdXNlIHRoZSBjb25jYXRlbmF0aW9uIGhlcmUuIEluIHNob3J0LCBJIHRo
aW5rIHRoYXQgaXQncyBhY3R1YWxseSBhbiBhZHZhbnRhZ2U6IHdlIGhhdmUgYW4gYWRkaXRpb25h
bCBoaW50IGhlcmUgdGhhdCBjb25jYXRlbmF0aW9uIGlzIHVuZGVzaXJlZC4gRXZlbiBjb21waWxh
dGlvbiB3YXJuaW5nIGNvdWxkIGJlIHBvc3NpYmxlIHRvIGltcGxlbWVudC48L2Rpdj48ZGl2Pjxi
cj48L2Rpdj48ZGl2PlNvLCBJIGRvbid0IHNlZSB0aGVzZSBwb2ludHMgYXMgcmVhbCBkaXNhZHZh
bnRhZ2VzLiBJIGRlZmluaXRlbHkgbGlrZSB0aGlzIGFwcHJvYWNoIG11Y2ggbW9yZSB0aGFuIGFk
ZGluZyBhbnkga2luZCBvZiBpbXBsaWNpdCBjb252ZXJzaW9uIG9yIGFub3RoZXIgbGl0ZXJhbCBz
eW50YXgsIHdoaWNoIHdvdWxkIGNvbXBsaWNhdGUgdGhlIHNwZWNpZmljYXRpb24gbXVjaCBtb3Jl
LjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48cD5JIGRvbid0IGJ1eSB0aGF0LCBzaW5j
ZSB0aGVyZSdzIGFscmVhZHkgU3RyaW5nLWFjY2VwdGluZyBBUEkgaW4gdGhlIHdpbGQsIHRoZW4g
d2UgY2FuIG5ldmVyIGJlIHNhZmVyIHRoYW4gdGhhdC4gU3RyaW5nLWFjY2VwdGluZyB2YXJpYW50
IGNhbiBiZSBkZXByZWNhdGVkLCBpZiBuZWVkcyBiZS48L3A+PHA+TWF1cml6aW88YnI+PC9wPjxi
cj4=" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0;">​</div>
    </div>
  </body>
</html>