On Thu, 23 Mar 2023 15:49:37 GMT, Jim Laskey <jlas...@openjdk.org> wrote:
>> 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`. 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). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146450918
