TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

JEP draft: String Templates (Final)

64 点作者 ludovicianul超过 1 年前

18 条评论

bruce343434超过 1 年前
I think having multiple processors is very smart exactly due to the outlined reason - making sure the interpolated result is safe for the system that will consume that string, be it a query language or json or something else.<p>f&quot;&quot; vs STR.&quot;&quot; is really a quite minimal difference, and I think worth it. Having the &quot;.&quot; operator here mean &quot;interpolate RHS using LHS&quot; seems a nice balance between terseness and explicitness.<p>As for &quot;\{&quot; being a divergent choice, frankly who cares.
评论 #38980874 未加载
评论 #38981323 未加载
frankjr超过 1 年前
It&#x27;s weird they didn&#x27;t mention JavaScript&#x27;s Tagged Templates because that&#x27;s exactly what they propose. Am I missing something?<p><a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;JavaScript&#x2F;Reference&#x2F;Template_literals?ref=triplet.fi#tagged_templates" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;JavaScript&#x2F;Refe...</a>
评论 #38981263 未加载
floodfx超过 1 年前
I think String Templates are pretty cool. For example it enables &quot;tagged template literal&quot;-like behavior which is super powerful in JS land.<p>I used it to support a LiveView implementation for Java: <a href="https:&#x2F;&#x2F;github.com&#x2F;floodfx&#x2F;undead">https:&#x2F;&#x2F;github.com&#x2F;floodfx&#x2F;undead</a><p>Sure the syntax isn&#x27;t &quot;pretty&quot; but understandable and you get used to it like anything else.
评论 #38980117 未加载
scotty79超过 1 年前
&gt; Thus if we forget to use a template processor such as STR, RAW, or FMT then a compile-time error is reported:<p><pre><code> String name = &quot;Joan&quot;; String info = &quot;My name is \{name}&quot;; | error: processor missing from template expression </code></pre> Were literals like &quot;\{&quot; always causing an error?
评论 #38980268 未加载
评论 #38980276 未加载
评论 #38980306 未加载
politelemon超过 1 年前
I wasn&#x27;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&#x27;d liked this to gain wider usage. For example that QueryBuilder they used for SQL would be useful.<p>Too often I see experienced developers using string interpolation for SQL and not realising it&#x27;s open to injection. I feel the document&#x27;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&#x27;s going to happen is people will only ever use STR.
评论 #38981151 未加载
评论 #38980446 未加载
评论 #38981059 未加载
david_allison超过 1 年前
Unpleasantly verbose, especially compared to Kotlin. They&#x27;d have come up with a much better approach if they had to add it to their list of current implementations.<p><pre><code> C# $&quot;{x} plus {y} equals {x + y}&quot; Visual Basic $&quot;{x} plus {y} equals {x + y}&quot; Python f&quot;{x} plus {y} equals {x + y}&quot; Scala s&quot;$x plus $y equals ${x + y}&quot; Groovy &quot;$x plus $y equals ${x + y}&quot; Kotlin &quot;$x plus $y equals ${x + y}&quot; JavaScript `${x} plus ${y} equals ${x + y}` Ruby &quot;#{x} plus #{y} equals #{x + y}&quot; Swift &quot;\(x) plus \(y) equals \(x + y)&quot; Java STR.&quot;\{x} plus \{y} equals \{x + y}&quot;</code></pre>
评论 #38980241 未加载
评论 #38980255 未加载
评论 #38980275 未加载
评论 #38980323 未加载
评论 #38980295 未加载
评论 #38980174 未加载
_old_dude_超过 1 年前
Both the syntax and the semantics are awful. They are overthinking it.<p>Processor should not require to allocate a list of objects do to string templating. Only STR and FMT get good perf because they are specialized by the compiler.
评论 #38990033 未加载
评论 #38986924 未加载
评论 #38982146 未加载
nikeee超过 1 年前
What&#x27;s Kotlin going to do about that? Will they adopt their syntax or make it use the same API internally?<p>This seems just like another feature of the JVM mother language that diverges from the implementation of other often-used JVM languages like Kotlin (thinking of nullability, type reification and structured concurrency and record types). It will be interesting to see what happens when Kotlin is continued to be pushed as the language for Android etc. while Java is being used by the majority of JVM devs.
评论 #38981389 未加载
评论 #38980671 未加载
hyperthesis超过 1 年前
It&#x27;s a whole new string: &quot; unescaped; multiline<p>In 1996, I thought java would be the new COBOL, and could endure for 20 years - now almost 30. This prioritization of &quot;whole product&quot; concerns, like security (bobby tables) and error-proneness, ensures longevity.<p>Also capture developers and codebases with its intricate magical features.
评论 #38980570 未加载
coldtea超过 1 年前
Would it hurt them to use ${x} instead of \{x}?<p>I mean, &quot;${x}&quot; could already be a literal in strings before, but they have the &lt;processor&gt;. prefix to the string, which no old code would have. One needs to actively use it, and so that someone can also actively check not to write an unescaped ${x} when they don&#x27;t want interpolation (like in other languages that use it).<p>Also the whole processor for escaping is imho ill-conceived. Escaping for a specific language like SQL should happen on the formatter instructions level, e.g.<p><pre><code> &quot;SELECT airport_code FROM airports WHERE name != &#x27;%sql.string\{surname}&#x27;&quot; -&gt; SELECT name FROM table_foo WHERE surname != &#x27;O&#x27;&#x27;Hare&#x27; </code></pre> or something to that effect (and similar for sql.identifier etc).<p>This way you could easily write classes with collections of methods to format a specific kind of language&#x27;s values - and not have write a full formatter that parses and understands the whole string in context (as I assume is the case now, if you don&#x27;t just use the naive STR&#x2F;FMT one, as 99% will do).<p>Especially since you might need to handle multiple languages escaping rules in the same template, if you include strings for multiple languges&#x2F;contexts in your template. What you do for that? Write the cartesian combo of template processors and make each understand and parse multi-language string tokens?
评论 #38990140 未加载
评论 #38980495 未加载
评论 #38980534 未加载
sitta超过 1 年前
The comments about this feature are always so tiresome. Please just scroll down and read the &quot;Alternatives&quot; section at the bottom. They&#x27;re not idiots. They&#x27;re working within backwards compatibility constraints. They can&#x27;t just do it like other languages.
评论 #38980220 未加载
评论 #38980264 未加载
评论 #38980184 未加载
评论 #38980325 未加载
评论 #38980318 未加载
评论 #38980451 未加载
rco8786超过 1 年前
In a word, horrible.<p>Classic Java though. Take a well established pattern, implement it 10 years late, and somehow make it worse.
评论 #38980881 未加载
评论 #38981122 未加载
评论 #38980499 未加载
acjohnson55超过 1 年前
This is great. This is an extremely useful feature in most other modern languages.<p>Why the heck did they make it so verbose, though, in terms of number of required characters?
评论 #38980563 未加载
评论 #38980250 未加载
scotty79超过 1 年前
How does those `interpolate()` methods reach into the surrounding context to get values of the variables?
评论 #38980466 未加载
lionkor超过 1 年前
conveniently left out C++ where it&#x27;s compile time verified (see std::format), and ofc Rust
评论 #38980512 未加载
AndrewOMartin超过 1 年前
The idea of allowing developers to define their own template formatter falls soundly into the &quot;Thanks, I hate it&quot; category for me. However, in willing to believe we might all be crowing for such power once the shock wears off and Java devs are enjoying their new found power.<p>On the other hand, the idea of having to know the details of a half-assed, janky, mini-DSL built in a panic by a dev who left six months ago fills me with dread.
评论 #38980237 未加载
评论 #38980444 未加载
评论 #38981596 未加载
exabrial超过 1 年前
Yep I’m that crunchy dev that thinks this is a lot of ceremony for something pretty useless and will just crowd&#x2F;uglify a codebase.<p>I don’t see why this is better than messageformat in any case? I think you might save typing like 6 whole characters? I don’t understand the value at all, perhaps I’m missing something? Just please no ‘it’s prettier’ nonsense.
shortrounddev2超过 1 年前
One of the ugliest implementations I&#x27;ve seen
评论 #38980309 未加载
评论 #38979860 未加载
评论 #38979964 未加载
评论 #38979943 未加载