Agree. Most of the time fragments are what are required. There are also
circumstances where having the full string is also useful. As you point, in the
doc, we discuss localization, where we use the interpolation string with
placeholders as the key to a "ResourceBundle" lookup.
During evaluation, we had the TemplatedString object provide access to both
string and list of fragments. This was done in a way to share these immutable
entities across all TemplatedString instances derived from a call site. No
recomputation required.
You should also note we defined TemplatedString as an interface. This gives us
a great deal of flexibility on how we resolve queries against an instance. So,
interop could be simple as deriving from TemplatedString.
Cheers,
-- Jim
> On Sep 17, 2021, at 7:49 AM, Tagir Valeev <amae...@gmail.com> 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://urldefense.com/v3/__https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals__;!!ACWV5N9M2RV99hQ!acICf3vYAnsi0s35BvYgUPE_tc2ViXGyTrMFkyB6XIkTUclqwEzoTFz4CDmEe-OcUA$
>>
>>
>> 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://urldefense.com/v3/__https://www.scala-lang.org/api/2.12.2/scala/StringContext.html__;!!ACWV5N9M2RV99hQ!acICf3vYAnsi0s35BvYgUPE_tc2ViXGyTrMFkyB6XIkTUclqwEzoTFz4CDlPJSYXLQ$
>>> 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://urldefense.com/v3/__https://github.com/openjdk/amber-docs/tree/master/site/design-notes/templated-strings.md__;!!ACWV5N9M2RV99hQ!acICf3vYAnsi0s35BvYgUPE_tc2ViXGyTrMFkyB6XIkTUclqwEzoTFz4CDmrNWsfyg$
>>>>> . After reading, we hope you'll see that the offering is much better
>>>>> than interpolation meat and potatoes.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> -- Jim
