freemarker-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Pontarelli (JIRA)" <>
Subject [jira] [Commented] (FREEMARKER-39) DefaultObjectWrapperBuilder isn't a Builder
Date Sun, 06 Nov 2016 14:25:58 GMT


Brian Pontarelli commented on FREEMARKER-39:

Technically you are correct that it is a builder (via GOF and others) since it builds things.
I should have been more explicit and said that it isn't a standard Java style builder. I don't
think there are many classes in Java that are named Builder that aren't fluent. Locale.Builder,
Calendar.Builder, StringBuilder, etc. Not to mention all the fluent builders in third-party
libraries: Guava, Commons, etc.

Also, the JavaBean specification is fine to stick to but not necessary for Builders by design.
Builders aren't usually designed to be used via reflection. Many of the JDK builders and other
systems use setters for the method names. However, like you said, you can add additional methods.

I will argue that providing a Fluent interface does reduce code, makes inlining possible and
will save people time. Plus, it just feels better almost all the time. Imagine the JDK Stream
interface not being fluent. Ouch.

I'm definitely looking forward to FreeMarker 3.0 (and maybe semantic versioning). I think
there are a lot of opportunities to clean house with a major release like that. Let me know
if you want a 10 year user's input on all the stuff that's "challenging" from the API and
template language. I'm sure you know most of it already though.

> 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