> On Mar 13, 2024, at 5:04 PM, Guy Steele <[email protected]> wrote: > >> On Mar 13, 2024, at 4:34 PM, Remi Forax <[email protected]> wrote: >> >> Given what Maurizio said and this, i think the only missing piece in the >> puzzle is what about existing methods taking a String as parameter. >> >> We know that for SQL.process(), we do not want process() to take a String >> but only a StringTemplate. >> But what about the existing methods that takes a String. >> >> Given a method Logger.warning(String), should >> LOG.warning($”CREATE TABLE foo;”); >> LOG.warning($”INSERT INTO foo (name, title) VALUES (\{other name}, \{other >> job});”); >> >> be legal ? Is there an auto-conversion (a kind of boxing conversion) from >> StringTemplate to String ? > > In my proposal, the answer would be “no”. Instead you would have two choices: > > (1) Instead of string template expressions as in the example just given, you > could use string literals or string interpolation expressions (omit the “$” > characters): > > LOG.warning(”CREATE TABLE foo;”); > LOG.warning(”INSERT INTO foo (name, title) VALUES (\{other name}, \{other > job});”); > > (2) If instead you have some other sort of expression (such as a variable) > whose type is StringTempate, you can write > > LOG.warning(String.of(myStringTemplate)); > > This makes quite explicit that a conversion is happening from StringTemplate > to String.
That reminds me: I would recommend that the instance method `toString` for class StringTemplate _not_ be the same as `String.of(Template)`; rather, it should print in some form that shows the internal structure of the StringTemplate. —Guy
