<i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v46]

[Jim Laskey]

On Thu, 23 Mar 2023 16:21:56 GMT, Rémi Forax <forax at openjdk.org> wrote:

>> It's coming back to me why we didn't do this in the first place (these projects tend to go on for months and years). `SimpleProcessor` exists because of that ugly second parameter, `E`, in `Processor<R, E>`, when a majority of the time `E` will be the unchecked `RuntimeException`. `StringProcessor` exists because 90+% of template processors will produce strings. From there, we originally had `Process.of`, `SimpleProcessor.of` and `StringProcessor.of`. We realized that the `@FunctionalInterface` route was cleaner and there was no need for `of` -- keep interfaces simple. I would argue that if you are creating a template processor, it is better to expose the result type and not bury in a `var`.
>
> Not a lot of people will write a processor and among those few, most of them will create a class that implement `Processor` (to have a proper name and a place to put documentation) so providing several reified names (`SimpleProcessor` and `StringProcessor`) is not that useful for implementers. For users, it's not something necessary to understand how processors work or how a specific processor should be used.
> 
> It looks like a loose loose situation for me, implementers do not need them and users will find them confusing (especially the difference between a processor and a simple processor).

"Not a lot of people will write a processor" I am not as confident as you. Once the cat is out of the bag that you can do magic (pending Guide to String Templates), processors will become a common idiom for designating string literals, especially text blocks.

But, I do agree that a majority will do old school classes with `process` methods along with several supporting methods. On the other  hand, the API itself uses function interfaces to define STR and RAW. I guess I'll have to do a pro/con chart.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146528863