We went back and forth a few times on this, and might go back and forth
some more. For many applications, the segments are valuable, though for
some, the full string is more useful.
Whether the framework or the policy object does String::split isn't
really that interesting; the real question is how to avoid doing it on
every invocation. There's a story for callsite caching of this and
more, but we'd like to nail down the basic programming model first.
On 9/17/2021 6:49 AM, Tagir Valeev wrote:
It's interesting that in both Scala and JavaScript when you define
custom interpolation policy, you get a collection of Strings instead
of a single string. So in the article, we see "error: file \{} not
found" but in Scala/JS you would get List.of("error: file ", " not
found")). While for localization, having a single string already baked
might be beneficial, I think in the general case, having separate
parts may be helpful for interpolation implementations, as no
additional parsing (search for \{}) would be necessary. Also, the
placeholder designation with \{} (or whatever else) is quite
arbitrary. If we just provide a list, we would not need to make this
choice. And probably the interop between JVM languages would be easier
(of course, Scala/Kotlin folks would like to use template policies
defined in Java, and vice versa).
Another alternative is to have a single list of template fragments,
something like this:
sealed interface TemplateFragment {
interface StringFragment extends TemplateFragment {
String content();
}
interface ExpressionFragment extends TemplateFragment {
Object content();
}
}
Now, TemplatedString is just a List of TemplateFragments (it's not
always necessary that ExpressionFragments should be interleaved with
StringFragments, you may have two ExpressionFragments next to each
other).
On Fri, Sep 17, 2021 at 5:38 PM Tagir Valeev <amae...@gmail.com> wrote:
As for custom template processing in JavaScript, see "Tagged
templates" section here:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals
On Fri, Sep 17, 2021 at 2:15 PM Tagir Valeev <amae...@gmail.com> wrote:
Btw people say that Scala provides a similar mechanism using
StringContext class:
https://www.scala-lang.org/api/2.12.2/scala/StringContext.html
In fact, Scala's `s` prefix before interpolated literal is a recipe
for interpolation provided by a standard library, not by language. And
it's possible to declare your own recipes. Quite similar to our
proposal.
Also, there's some frustration in Twitter comments regarding the
article narrative like "We will do it better than existing languages"
(especially because Scala was chosen as an example). Probably, the
wording could be better, with more respect to other languages. Of
course, this doesn't undermine the suggested feature itself, the
feature is great.
With best regards,
Tagir Valeev.
On Fri, Sep 17, 2021 at 9:35 AM Tagir Valeev <amae...@gmail.com> wrote:
Hello!
Just read the proposal. I don't have any useful comments for now. For
me, the proposal looks great as is. Go ahead and implement it :D
With best regards,
Tagir Valeev.
On Thu, Sep 16, 2021 at 8:28 PM Jim Laskey <james.las...@oracle.com> wrote:
Amber experts,
Now that JDK 17 has been plated and left the kitchen, we should have a look-see
at one of the new menu items Brian and I have had on a slow boil for these last
few months; Templated Strings.
Before you start shouting out, "Templated Strings? This isn't what I ordered! The
subject said string interpolation!!!", take the time to follow this link
https://github.com/openjdk/amber-docs/tree/master/site/design-notes/templated-strings.md.
After reading, we hope you'll see that the offering is much better than interpolation
meat and potatoes.
Cheers,
-- Jim
