[
https://issues.apache.org/jira/browse/FREEMARKER-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787540#comment-17787540
]
Simon commented on FREEMARKER-183:
----------------------------------
_*An exploration of a record component being a property value, except when you
call it with brackets*_
_Note: this concept does mean that you would be unable to treat the component
as a real method that you can assign to a variable and pass around._
So at the moment, for the record component name, we return a Method from
ClassIntrospector. If we try to change it to return a FastPropertyDescriptor,
then when using brackets to do an invocation, MethodCall receives the
TemplateModel of the invocation result (when using eval on the Expression),
rather than the TemplateMethodModel it expects.
The MethodCall contains a Dot and that will receive a BeanModel from the
evaluated target, which will then be recognized as a TemplateHashModel and
{{get}} will be called.
Looking at {{{}BeanModel.get{}}}, it calls {{invokeThroughDescriptor}} and
there we find the logic to either invoke a FastPropertyDescriptor's accessor
method or to wrap a Method with a SimpleMethodModel.
So... noting that BeanModel can already do both behaviors, perhaps we could
make this more dynamic and allow MethodCall to provide a hint at what it wants
(the argument would be {{TemplateMethodModel.class}} in this case), to prevent
the accessor method being invoked by {{{}BeanModel.get{}}}?
1. We would enhance Expression.eval to allow passing that hint
2. We probably shouldn't enhance {{TemplateHashModel.get}} to accept a hint, so
perhaps instead we could have BeanModel implement an optional interface that
Dot could check for and prefer calling an extended get method when it's found
to be available.
3. BeanModel should only obey this hint if we use a variant of
FastPropertyDescriptor that says that it supports doing this (i.e. only for
record component accessors). This is unnecessary for normal beans, since in
that case the property and method names are different and so we don't have any
problems.
Is this acceptable or too horrible to contemplate?
> Add support for Java records
> ----------------------------
>
> Key: FREEMARKER-183
> URL: https://issues.apache.org/jira/browse/FREEMARKER-183
> Project: Apache Freemarker
> Issue Type: Task
> Reporter: Dániel Dékány
> Assignee: Dániel Dékány
> Priority: Major
>
> Currently we don't support records (JEP 395), which was finalized in Java 16.
> Users can extend {{DefaultObjectWrapper}} for that of course, but it should
> be supported out of the box.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
