添加链接
link管理
链接快照平台
  • 输入网页链接,自动生成快照
  • 标签化管理网页链接
相关文章推荐
英勇无比的莴苣  ·  Better error message ...·  1 周前    · 
爱热闹的葫芦  ·  Column.IsIdentity ...·  1 周前    · 
兴奋的玉米  ·  Mapping Attributes✨ | ...·  1 周前    · 
讲道义的仙人掌  ·  Create Table ...·  5 月前    · 
高大的夕阳  ·  TensorRT部署方案介绍·  8 月前    · 
稳重的自行车  ·  NVIDIA - TensorRT | ...·  1 年前    · 
Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

This question is related to ( Why is there no string interpolation in Scala? ), but deals more specifically with multi-line strings.

I've just about bought into Martin's suggestion for simple string placeholder where msg = "Hello {name}!"

can be be represented without much difference in Scala today like this: msg = "Hello"+name+"!"

However, I don't think that approach holds with multi-line strings. And, in some cases it may be encouraging other poor practices in favor of readability. Note that in the Scala Play ANORM database mapping how the framework tries to preserve readability in plain SQL (using placeholders), but at the expense of duplicating the {countryCode} variable name and in a non-type-safe way, see... .on("countryCode" -> "FRA")

select * from Country c join CountryLanguage l on l.CountryCode = c.Code where c.code = {countryCode}; ).on("countryCode" -> "FRA")

Additionally, assuming no change in Scala to address this, what would be the implication of using inline XML? How would performance, memory, etc. with something like:

val countryCode = "FRA"
SQL(<c>        
  select * from Country c 
  join CountryLanguage l on l.CountryCode = c.Code 
  where c.code = {countryCode};
</c>.text)
                One drawback of the literal XML hack is that it is evaluated only one time. Also note that the enhanced string compiler plugin looks promising but with questionable maintenance: github.com/jrudolph/scala-enhanced-strings
– eptx
                May 3, 2011 at 5:47

A scala.xml.Elem would be constructed which had the string contents represented as an ArrayBuffer, chopped up for every { } substitution. I'm certainly no authority but I believe what would happen is that there's a little extra overhead in construction the object and then getting the children and concatenating them together at runtime but, at least in this example, as soon as it's passed to the SQL function which then extracts the string it wants (or perhaps this would be done with an implicit) the Elem object would be discarded so there'd be a little extra memory usage, but only briefly.

But in the bigger picture, I don't think it's performance that would hinder the adoption of this solution but I guess a lot of people would be uncomfortable abusing XML in this way by using a made-up tag. The problem would be with other users reading the code later trying to figure out the semantic meaning of the tag... only to find there isn't one.

The example you give is almost certainly not doing string concatenation, it's creating parameterized SQL statements (probably via JDBC's PreparedStatement).

Ironically, the lack of easy string concatenation is probably slightly encouraging best practices in this case (although I certainly wouldn't use that as an argument either way on the topic).

Please clarify how you see the lack of string concatenation encouraging best practices in this case. – eptx May 3, 2011 at 5:37

If you are coming to this question from the future, multi-line string interpolation is now a thing.

val when = "now"
println(s"""this is $when a thing.""")
// this is now a thing
        

Thanks for contributing an answer to Stack Overflow!

  • Please be sure to answer the question. Provide details and share your research!

But avoid

  • Asking for help, clarification, or responding to other answers.
  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.