StringTemplates name changes

[Brian Goetz]

Nice.

So that means java.lang additions are limited to StringTemplate (with 
nested Processor), and public jl.runtime limited to 
Template{Runtime,Support}.

In the spirit of "nothing left to take away", who are the methods in 
TemplateSupport used by?  Authors of processors? There's not too much 
here -- creation, interpolation, combination.  Would these make sense as 
static helper methods on STringTemplate?  They'd be more discoverable 
there.


On 3/27/2023 9:07 AM, Jim Laskey wrote:
>
> After the string template interface name changes, i.e., 
> |TemplateProcessor| becoming |Processor|, the rationale for the 
> existence of |SimpleProcessor |and |StringProcessor| has lessened to 
> the point where they should be dropped.
>
> |SimpleProcessor| owed its existence to the long-winded name 
> |TemplateProcessor| and that ugly second parameter, |E|, in 
> |Processor<R, E>| (in a many of cases |E| will be the unchecked 
> |RuntimeException|). |StringProcessor| existed because most template 
> processors will produce strings.
>
> |TemplateProcessor<JSONObject, RuntimeException> JSON = st-> new 
> JSONObject(st.interpolate()); TemplateProcessor<String, 
> RuntimeException> INTER = StringTemplate::interpolate;|
>
> vs.
>
> |SimpleProcessor<JSONObject> JSON = st-> new 
> JSONObject(st.interpolate()); StringProcessor INTER = 
> StringTemplate::interpolate;|
>
> It was thought that having the friendlier interfaces would provide 
> clarity, hide |RuntimeException| and simplify explanation. The reality 
> is that most developers will define template processors using full 
> class declarations. Furthermore, developers will learn to use 
> |RuntimeException| regularly due to the abundance of template 
> processor examples.
>
> |public class InterpolateProcessor implements Processor<String, 
> RuntimeException> { @Override public String process(StringTemplate st) 
> { return st.interpolate(); } } SimpleProcessor<String> INTER = new 
> InterpolateProcessor(); |
>
> Even after |SimpleProcessor| and |StringProcessor| go away, developers 
> can still use the functional interface shorthand.
>
> |Processor<JSONObject, RuntimeException> JSON = st-> new 
> JSONObject(st.interpolate()); Processor<String, RuntimeException> 
> INTER = StringTemplate::interpolate;|
>
> And, a new factory method, |Processor.of|, will be added for fans of 
> |var|.
>
> |var JSON = Processor.of(st-> new JSONObject(st.interpolate())); var 
> INTER = Processor.of(StringTemplate::interpolate);|
>
> For those developers that like the notion of |SimpleProcessor| and 
> |StringProcessor|, these interfaces can be trivially defined per project;
>
> |@FunctionalInterface public interface SimpleProcessor<R> extends 
> Processor<R, RuntimeException> {} @FunctionalInterface public 
> interface StringProcessor extends SimpleProcessor<String> {}|
>
>
>
>
>
>
>> On Mar 17, 2023, at 10:24 AM, Jim Laskey <james.laskey at oracle.com> wrote:
>>
>> This is a  heads up about some name changes coming to the string 
>> template feature with the intent of eliminating the 
>> “java.lang.template” package along with clarifying the processor 
>> hierarchy,
>>
>> _Old_ 	_New_
>> java.lang.template.Carriers* 	java.lang.runtime.Carriers*
>> java.lang.template.ReferencedKeyMap* 
>> java.lang.runtime.ReferencedKeyMap*
>> java.lang.template.ReferenceKey* 	java.lang.runtime.ReferenceKey*
>> java.lang.template.StringTemplateImpl* 
>> java.lang.runtime.StringTemplateImpl*
>> java.lang.template.StringTemplateImplFactory* 
>> java.lang.runtime.StringTemplateImplFactory*
>> java.lang.runtime.TemplateRuntime 	java.lang.runtime.TemplateRuntime
>> java.lang.template.TemplateSupport* 	java.lang.runtime.TemplateSupport
>> java.lang.template.StringTemplate 	java.lang.StringTemplate
>> java.lang.template.ValidatingProcessor 
>> java.lang.StringTemplate.Processor
>> java.lang.template.ProcessorLinkage 
>> java.lang.StringTemplate.Processor.Linkage
>> java.lang.template.TemplateProcessor 
>> java.lang.StringTemplate.SimpleProcessor
>> java.lang.template.StringProcessor 
>> java.lang.StringTemplate.StringProcessor
>>
>>
>> (*) - package private
>>
>>
>> The new processor hierarchy will be;
>>
>> interface Processor<R, E>
>> interface SimpleProcessor<R> extends Processor<R, RuntimeException>
>> interface StringProcessor extends SimpleProcessor<String>
>>
>> It will take me a few days to update the JEP, CSRs, PR and JLS, so 
>> stay tuned. As always, comments are welcome.
>>
>> Cheers,
>>
>> — Jim
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20230327/5d53351b/attachment-0001.htm>