Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 3853E200BB5 for ; Sun, 6 Nov 2016 19:38:19 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 33D26160AFC; Sun, 6 Nov 2016 18:38:19 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 78FCA160AE8 for ; Sun, 6 Nov 2016 19:38:18 +0100 (CET) Received: (qmail 10486 invoked by uid 500); 6 Nov 2016 18:38:17 -0000 Mailing-List: contact notifications-help@freemarker.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@freemarker.incubator.apache.org Delivered-To: mailing list notifications@freemarker.incubator.apache.org Received: (qmail 10477 invoked by uid 99); 6 Nov 2016 18:38:17 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Nov 2016 18:38:17 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 31D75C03B7 for ; Sun, 6 Nov 2016 18:38:17 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.999] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id N9PrXiKJxS8a for ; Sun, 6 Nov 2016 18:38:15 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with SMTP id B3DAA5F3BC for ; Sun, 6 Nov 2016 18:38:14 +0000 (UTC) Received: (qmail 9701 invoked by uid 99); 6 Nov 2016 18:36:59 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Nov 2016 18:36:59 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id D9BB62C2A6A for ; Sun, 6 Nov 2016 18:36:58 +0000 (UTC) Date: Sun, 6 Nov 2016 18:36:58 +0000 (UTC) From: "Daniel Dekany (JIRA)" To: notifications@freemarker.incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (FREEMARKER-39) DefaultObjectWrapperBuilder isn't a Builder MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Sun, 06 Nov 2016 18:38:19 -0000 [ https://issues.apache.org/jira/browse/FREEMARKER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15642207#comment-15642207 ] Daniel Dekany edited comment on FREEMARKER-39 at 11/6/16 6:36 PM: ------------------------------------------------------------------ I agree that fluent API-s would be nice, I 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. was (Author: ddekany): 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 > {code} > And the parent class is defined like this: > {code:title=DefaultObjectWrapperConfiguration.java} > public abstract class DefaultObjectWrapperConfiguration extends BeansWrapperConfiguration { > {code} > That the final parent class is defined like this: > {code:title=BeansWrapperConfiguration.java} > public abstract class BeansWrapperConfiguration implements Cloneable > {code} -- This message was sent by Atlassian JIRA (v6.3.4#6332)