Does any one know what are the advantages of STR."templ" syntax vs STR("templ")?
JEP 430: String Templates (Preview) Proposed to Target Java 21
81–90 of 246 posts
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#82Why oh why is that a backslash!? Over the 9 languages mentioned: 5 languages (inc. JVM ones like groovy and kotlin) are using `$`, 1 language (swift) is using `\`. `\` is a pain to type on many keyboard layouts -- actually most but the US one. It seemed to me that `$` would have been a much more "conventional" choice. This really makes me sad. It looks like the choice was made on purpose to be different.
I don't understand this rationale either: > For the syntax of embedded expressions we considered using ${...}, but that would require a tag on string templates (either a prefix or a delimiter other than ") to avoid conflicts with legacy code. Can't the template processor expression itself function as the tag? Is STR."..." already legal now?
They want
String info = "My name is \{name}.";
String info = "My name is ${name}.";
———
However, what they could have done instead is to use a syntax like
String info = "My name is "(name)".";
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#83Earlier quoted context omitted.
Right, and that's why Java introduced checked exceptions in 1.0. A feature which wasn't proven back then and remains unproven now. Another example being overengineered streams. Parallel streams look really cool as a demo, but have been proven dangerous in their default configuration (they can exhaust the default thread pool).
Checked exceptions are exact analogs to Result types, but better (auto-unwrap, bubble up, stack traces). It is unfortunately far from flawless (inheritance is not a great combo with it), but that has been part of the language since the beginnings. Streams are not a language feature, it is only a library. And I honestly don’t find them over-engineered, they really make plenty of logics very readable.
Exceptions have implied control flow which makes them strictly worse than the Result types which are, as their name suggests, just types.
Imagine if some other common types had unrelated features like this baked into them. Want a string? Sorry in my new language all the strings need their own separate thread for some reason.
Actually sorry, I forgot, we're in a Java topic, Java actually did have features baked into types. All of Java's user defined types insisted on living on the heap. Just want to make a pair of integers? Sorry, that's an Object now and so it lives on the heap, whereas just one integer is fine, those are just local stack variables. Did they fix that yet?
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#84Why oh why is that a backslash!? Over the 9 languages mentioned: 5 languages (inc. JVM ones like groovy and kotlin) are using `$`, 1 language (swift) is using `\`. `\` is a pain to type on many keyboard layouts -- actually most but the US one. It seemed to me that `$` would have been a much more "conventional" choice. This really makes me sad. It looks like the choice was made on purpose to be different.
I assume because `\{` was not a valid escape sequence, which means any use of this character pair can be identified as a template without changing the semantics of existing string literals.
More specifically: https://news.ycombinator.com/item?id=35016204
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#85One thing I'm not sure is possible in this proposal, is there a way to make the interpolation "lazy", such that the string (and the evaluation of its interpolated components) can be skipped if the string isn't ultimately used? In swift, there's some nice quasi-laziness you can add to function parameters, so that (say) a logging function that can fully skip evaluating a string sent to it with the `@autoclosure` syntax…
You probably would pass the equivalent of
new Object() { public String toString() { return
; } }
STR."\{lazy(() -> )}"Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#86Earlier quoted context omitted.
Back in 1997, when James Gosling outlined his vision for Java, he said it should be a conservative language (wrapping a very innovative runtime) that would ideally only adopt features that have proven themselves, for some time, in other languages. Being a last mover is at the very core of Java's evolution strategy. It's not playing catch-up because we're not trying to adopt all features other, more "adventurous", lan…
Yeah, you're mostly right, but then... generics.
I think it’s being worked on and they have an idea/solution.
But Java lives and dies by backwards compatibility so they have to be very careful about it.
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#87Earlier quoted context omitted.
Checked exceptions are exact analogs to Result types, but better (auto-unwrap, bubble up, stack traces). It is unfortunately far from flawless (inheritance is not a great combo with it), but that has been part of the language since the beginnings. Streams are not a language feature, it is only a library. And I honestly don’t find them over-engineered, they really make plenty of logics very readable.
Exceptions have implied control flow which makes them strictly worse than the Result types which are, as their name suggests, just types. Imagine if some other common types had unrelated features like this baked into them. Want a string? Sorry in my new language all the strings need their own separate thread for some reason. Actually sorry, I forgot, we're in a Java topic, Java actually did have features baked into t…
Checked exceptions are explicit. They are no weirder than doing do-notation in an Either monad, the syntax could be more ergonomic but they are clear as day.
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#88Earlier quoted context omitted.
Java's syntax is just as friendly and simple -- see my other comments on the subject -- it just requires the receiver to define a policy, which is essential for security. You only need to use STR when the receiver does not define a template processor and works with strings. I have no idea what Python's or JS's security experts advised, but that code injection is one of the most common vulnerabilities in memory-safe l…
I’m not a fan of the special `log.info."x: \{x}";` syntax, it looks like a weird mix of field access and a string literal. And even with the fancy new syntax, I’m sure there will be people passing STR."SELECT * FROM x WHERE y = \{y}" to their database. You can educate people all you want, but not all developers will read the docs telling them this is dangerous. Even if all the docs do the right thing, people might en…
Well, you know, even thirty years of experience as the custodians of one of the most successful programming languages is no guarantee of success with every feature, but that's why we have the preview process now that lets us figure out what problems people actually encounter -- which may well be different from the problems they, or we, think they would encounter -- before finalising the feature.
Just remember that you can't pass a string to an API that doesn't take strings, and even with existing APIs, methods that take strings can be deprecated to cause compiler warnings. So sometimes there are stronger ways than just documentation to discourage dangerous code.
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#89Earlier quoted context omitted.
It’s not as bad as people make it out to be. Swift without any backwards compatibility constraints chose “\(val)”. It does need a slight getting used to but it is not any worse than ${}.
Swift’s choice is strange and ugly IMO, even if it did not involve backwards compatibility constraints.
For another n=1 opinion, I like Swift’s choice, even though it’s different from convention. It’s lighter, typographically. ‘${‘ draws more attention to the delimiters than ‘\(‘.
And yes, the delimiters could be made less obtrusive using syntax coloring, but not all tools will do that (e.g. when using grep on a code base)
Re: JEP 430: String Templates (Preview) Proposed to Target Java 21
#90Earlier quoted context omitted.
Checked exceptions are exact analogs to Result types, but better (auto-unwrap, bubble up, stack traces). It is unfortunately far from flawless (inheritance is not a great combo with it), but that has been part of the language since the beginnings. Streams are not a language feature, it is only a library. And I honestly don’t find them over-engineered, they really make plenty of logics very readable.
Exceptions have implied control flow which makes them strictly worse than the Result types which are, as their name suggests, just types. Imagine if some other common types had unrelated features like this baked into them. Want a string? Sorry in my new language all the strings need their own separate thread for some reason. Actually sorry, I forgot, we're in a Java topic, Java actually did have features baked into t…
Regarding user-defined types, probably what you're looking for is JEP 401: Primitive Classes (Preview) [1]. I believe it's currently being worked on.