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

[Jim Laskey]

On Thu, 23 Mar 2023 15:01:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> You can, of course, reduce this to;
>> 
>> 
>> interface Processor {
>>  
>>     ...
>>     
>>     static <T> StringTemplate.Processor<T, RuntimeException> of(Function<StringTemplate, T> function) {
>>         return function::apply;
>>     }
>>     
>>     ...
>> 
>> }
>> 
>> var simple = Processor.of(st-> new JSONObject(st.interpolate()));
>> var string = Processor.of(StringTemplate::interpolate);
>> 
>> 
>> since String is just a type. This proposal has merit and worth some thought. -2 interfaces, +1 method.
>
> On the flip side, for those that don't use `var`;
> 
> 
> Processor<JSONObject, RuntimeException> simple = Processor.of(st-> new JSONObject(st.interpolate()));
> Processor<String, RuntimeException> string = Processor.of(StringTemplate::interpolate);
> 
> 
> vs.
> 
> 
> SimpleProcessor<JSONObject> simple = st-> new JSONObject(st.interpolate());
> StringProcessor string = StringTemplate::interpolate;

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`.

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

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