[
https://issues.apache.org/jira/browse/FREEMARKER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15642207#comment-15642207
]
Daniel Dekany commented on FREEMARKER-39:
-----------------------------------------
I agree that fluent API-s would be nice, I'm just suspect that it causes more
annoyance than good in 2.x, as it will cause warnings in existing projects (if
I'm not mistaken), while you rarely configure FreeMarker for many times per
project (compared to, say, using Java 8 stream API, Guava API-s, etc.).
Just as a side note, since we would use {{foo(value)}} anyway, JavaBean
properties are used on many places, such as in Spring IoC (and these builders
are more like String {{FactoryBean}}-s actually), Groovy, Kotlin, etc. I'm not
sure if they are all immune to setters with return values.
Any input for FreeMarker 3 is welcome on the
[email protected] list! And especially if and when I manage
to bootstrap that activity, having people around with past experience will be
important. I'm not saying that everyone's pet beeves will be addressed, in fact
most won't be, because I believe it's important to have consistent and focused
"vision", but I'm still listening.
BTW, I was thinking if we should ditch visible bean constructors for
configuration-related beans in 3.x, an only have builders (or bean factories as
Spring calls them), because then the resulting objects can be strictly
immutable. It has caused some complications in 2.x that it's not the case.
> DefaultObjectWrapperBuilder isn't a Builder
> -------------------------------------------
>
> Key: FREEMARKER-39
> URL: https://issues.apache.org/jira/browse/FREEMARKER-39
> Project: Apache Freemarker
> Issue Type: Improvement
> Components: engine
> Affects Versions: 2.3.25-incubating
> Reporter: Brian Pontarelli
>
> This might not be considered a bug, but I'm logging it as one rather than an
> improvement. The class {{DefaultObjectWrapperBuilder}} is not actually a
> builder right now and it makes using it inline impossible.
> To make it a more standard Builder pattern, all of the setter methods should
> be updated so that the return type is {{DefaultObjectWrapperBuilder}} and the
> method does a {{return this;}} at the end. This will make method chaining
> possible and inline use also possible. Since it uses inheritance extensively
> (you might want to consider unwinding this as well), you'll need to use
> generics and return T. Here's the class definition so that T works:
> {code:title=DefaultObjectWrapperBuilder.java}
> public class DefaultObjectWrapperBuilder extends
> DefaultObjectWrapperConfiguration<DefaultObjectWrapperBuilder>
> {code}
> And the parent class is defined like this:
> {code:title=DefaultObjectWrapperConfiguration.java}
> public abstract class DefaultObjectWrapperConfiguration<T> extends
> BeansWrapperConfiguration<T> {
> {code}
> That the final parent class is defined like this:
> {code:title=BeansWrapperConfiguration.java}
> public abstract class BeansWrapperConfiguration<T extends
> BeansWrapperConfiguration> implements Cloneable
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
