On Thu, 23 Mar 2023 16:21:56 GMT, Rémi Forax <fo...@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
