[Correction] Re: [string-templates] Covariant signature of 'process' method
Tagir Valeev
amaembo at gmail.com
Thu Aug 3 10:10:13 UTC 2023
Unfortunately, I mixed the sample code. The first code sample in my
previous letter should read as:
public class Test {
static class MyProcessor implements
StringTemplate.Processor<Integer, Exception> {
@Override
public Integer process(StringTemplate stringTemplate) {
return 123;
}
}
public static void main(String[] args) {
MyProcessor proc = new MyProcessor();
Integer i = proc."hello";
}
}
The second sample should read as:
public class Test {
static class MyProcessor implements
StringTemplate.Processor<Object, RuntimeException> {
@Override
public Integer process(StringTemplate stringTemplate) {
return 123;
}
}
public static void main(String[] args) {
MyProcessor proc = new MyProcessor();
Integer i = proc."hello";
}
}
Sorry for the confusion.
With best regards,
Tagir Valeev.
On Thu, Aug 3, 2023 at 12:07 PM Tagir Valeev <amaembo at gmail.com> wrote:
>
> Hello!
>
> It's possible to create a custom string template with covariant
> process() method signature. For example, we can relax the throws
> statement:
>
> public class Test {
> static class MyProcessor<T> implements
> StringTemplate.Processor<Integer, Exception> {
> @Override
> public Integer process(StringTemplate stringTemplate) {
> return 123;
> }
> }
>
> public static void main(String[] args) {
> MyProcessor<String> proc = new MyProcessor<>();
> Integer i = proc."hello";
> }
> }
>
> Now, it's not compilable:
> java: unreported exception java.lang.Exception; must be caught or
> declared to be thrown
>
> However, it's evident and can be statically checked that the exception
> is not possible.
>
> Covariant return type is also possible:
>
> public class Test {
> static class MyProcessor implements
> StringTemplate.Processor<Integer, Exception> {
> @Override
> public Integer process(StringTemplate stringTemplate) {
> return 123;
> }
> }
>
> public static void main(String[] args) {
> MyProcessor proc = new MyProcessor();
> Integer i = proc."hello";
> }
> }
>
> Now, it's not compilable:
> java: incompatible types: java.lang.Object cannot be converted to
> java.lang.Integer
>
> This requires passing exact types through the inheritance hierarchy
> which might be inflexible and annoying. I may probably want to declare
> `abstract class AbstractProcessor implements Processor<Object,
> Throwable>` and have any covariant signatures in subtypes without
> declaring new type parameters and forward them through the hierarchy.
>
> Java has another implicit way to call methods: try-with-resources and
> AutoCloseable interface. There we have no exception type parameter,
> but covariant signatures in subclass close() methods are respected at
> the try-with-resource use sites. Probably it would be more consistent
> and convenient to respect covariant signatures in string templates as
> well?
>
> With best regards,
> Tagir Valeev.
More information about the amber-spec-experts
mailing list