The String template API is about the processor, not the template

[David Alayachew]

I think you are correct.

Annoyingly enough though, it's a whole lot of rework in the name of clarity.

That said, since it is in preview, I would think that that is still very
much the right thing to do (and the right time to do it). Not sure how much
benefit you would get for this though.

On Fri, Sep 15, 2023 at 12:27 PM Remi Forax <forax at univ-mlv.fr> wrote:

> I know that I'm asking a lot, but I believe the way the String template
> JEP is written and the API is designed uses the wrong center.
>
> This spec is not about the string template, it's about the template
> processor, the string template is just a parameter of the processor.
>
> This was not true historically, StringTemplate was the design center.
> But when we required the syntax to be always prefixed by a template
> processor, we have make the template processor the new design center.
>
> Currently the API is designed with the processor interface defined as a
> member interface of StringTemplate.
> I think we should go the other way around, the top level construct should
> be the interface TemplateProcessor and StringTemplate should be defined as
> a member of TemplateProcessor.
>
> If you think about it, a lot of our users may use a TemplateProcessor but
> only few will either implement a template processor or use RAW, so knowning
> what a StringTemplate is a not something most of our users will have to
> learn.
>
> regards,
> Rémi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20230915/d58728ad/attachment.htm>