Mailing-List: contact notifications-help@freemarker.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@freemarker.incubator.apache.org
Date: Sun, 6 Nov 2016 18:35:59 +0000 (UTC)
From: "Daniel Dekany (JIRA)" <jira@apache.org>
To: notifications@freemarker.incubator.apache.org
Message-ID: <JIRA.13018631.1478368705000.203644.1478457359649@Atlassian.JIRA>
In-Reply-To: <JIRA.13018631.1478368705000@Atlassian.JIRA>
References: <JIRA.13018631.1478368705000@Atlassian.JIRA> <JIRA.13018631.1478368705760@arcas>
Subject: [jira] [Commented] (FREEMARKER-39) DefaultObjectWrapperBuilder
 isn't a Builder
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sun, 06 Nov 2016 18:36:40 -0000


    [ 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 dev@freemarker.incubator.apache.org 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)