freemarker-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Dekany (JIRA)" <>
Subject [jira] [Commented] (FREEMARKER-39) DefaultObjectWrapperBuilder isn't a Builder
Date Sun, 06 Nov 2016 18:35:59 GMT


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

Any input for FreeMarker 3 is welcome on the 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:
>             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:
> {}
> public class DefaultObjectWrapperBuilder extends DefaultObjectWrapperConfiguration<DefaultObjectWrapperBuilder>
> {code}
> And the parent class is defined like this:
> {}
> public abstract class DefaultObjectWrapperConfiguration<T> extends BeansWrapperConfiguration<T>
> {code}
> That the final parent class is defined like this:
> {}
> public abstract class BeansWrapperConfiguration<T extends BeansWrapperConfiguration>
implements Cloneable
> {code}

This message was sent by Atlassian JIRA

View raw message