On Thu, 23 Mar 2023 15:01:27 GMT, Jim Laskey <jlas...@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
