Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.apache.org
Subject: Re: Proposal: Statically compileable builders
To: dev@groovy.apache.org
References: <CAO_wNoeC-9a46NoZn3gm0c1tX4omHbNfXhvF7ZDD=o88ZrsyuQ@mail.gmail.com>
 <3ecaeb92-df79-2240-5af9-a13b9011bb9c@gmx.org>
 <CAO_wNocu+yyEKu55s5s_ecye3EY3XqooXjgqXzHXDeXXHkF_Wg@mail.gmail.com>
 <57F412A1.9020506@gmx.org>
 <CAO_wNofdoHs+_jT1HpcTJcjokmRTDP7Hmcw_eB1DDZHAmMoFGQ@mail.gmail.com>
From: Jochen Theodorou <blackdrag@gmx.org>
Message-ID: <57F5394C.3090603@gmx.org>
Date: Wed, 5 Oct 2016 19:33:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <CAO_wNofdoHs+_jT1HpcTJcjokmRTDP7Hmcw_eB1DDZHAmMoFGQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
archived-at: Wed, 05 Oct 2016 17:33:09 -0000

On 05.10.2016 08:13, Graeme Rocher wrote:
[...]
> So again let's revisit the benefits of this change:
>
> 1) You can write classes annotated with @CompileStatic and use
> builders without having to compromise the design of your code
> 2) You can get type checking for non-builder methods if concrete types
> are used in methodMissing (example "methodMissing(String, Closure)"
> and type checking for properties if "propertyMissing" is not defined
> 3) You will get better performance and no matter what we do to the
> dynamic side that will stay the same
> 4) Our goal should be that as much code as possible is compileable
> with @CompileStatic and this change helps that

I would appreciate to exclude (1) from the discussion for now. Third 
party bias and fears will not lead to a constructive discussion.

Then for (2)... methodMissing(String, Closure) will not get you anywhere 
in terms of type checking. This is for methods "foo{...}" or "bar{...}", 
where bar and foo are the String. If you write foobar instead, there is 
nothing preventing compilation and failure at runtime. And it does not 
scale: The more methodMissing you have, the less likely there is the 
chance for a compilation error due to builder method argument. And I 
actually still fail to see how you want to use this with 
@DelegateTo(Map), unless all builder methods of that form will have 
these properties.

(3) depends on the implementation. Your suggestion will not give the 
best performance, neither in the static, nor in the dynamic world. Which 
really makes it difficult for me to see the performance argument. You 
are right in that using something like categories will make performance 
degrade of course.

And (4)... looks more like a result of (1) to me and will not help 
discussion.. Unless you say you only want a builder that will pass 
static compilation and don´t care about real type checking and 
performance. In that case we can shorten this discussion a lot.


bye Jochen