[
https://issues.apache.org/jira/browse/FREEMARKER-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17794365#comment-17794365
]
Dániel Dékány commented on FREEMARKER-183:
------------------------------------------
I think I will attempt this too, in my own POC branch, a bit differently, and
see if I missed something.
First difference: I will try to encapsulate the decision of when the {{()}} is
optional inside {{{}MethodAppearanceDecision.setDefaults(Method){}}}. Then
users will be able to customize the policy with a
{{{}MethodAppearanceFineTuner{}}}. Also, then we can provide multiple policies
out-of-the-box as {{MethodAppearanceFineTuner}} implementations.
Second difference: I will try to deal with the hinting aspect of this on the
parser (AST) level. Because, I don't think that this should be a runtime
decision (like this "magic" shouldn't happen when you pass around the member in
a variable), but rather an intent that the user expresses syntactically on the
call place. That's like in Java, where the meaning of the dot (if it looks for
a field, or a method of the given name) is decided during parsing, based on if
it syntactically looks like method call. In your POC, hint passing happens on
runtime instead, by passing the desired result type as the 2nd argument to
{{{}Expression.eval{}}}. I understand that that's more generic than what I
propose here, but my bet is that we won't need that level of sophistication
often enough to justify the extra cognitive load that this brings for
developers (mostly only for the contributors), and also the small runtime
overhead that it adds to all {{{}Expression{}}}-s (unless the JIT optimizes it
out).
Regarding the behaviour that we want to reach at the end. We are "lucky" to be
bound by backward compatibility. Also, for a default behavior, I lean towards
the principle of least surprise (except when the users will keep shooting
themselves on the foot, because it's such bad practice). Therefore, I say,
first we just want the optional {{()}} magic to work for record components.
But, I want also add {{MethodAppearanceFineTurner}} that implements the
{{zeroArgumentMethodsAreProperties}} policy. Its horrible that then you can
write {{obj.lanuchNukes}} without the {{{}(){}}}, and it will still launch the
nukes (assuming that method has non-{{{}void{}}} return type), but Java doesn't
add the information needed to know the semantics, and they are creating this
new convention (of leaving out "get"/"is" from the name), and also it won't be
the default (for now) so this is probably a good compromise.
> 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)
