groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ledbrook <pe...@cacoethes.co.uk>
Subject Re: Automatic closure coercion and delegate
Date Wed, 18 May 2016 06:46:00 GMT
I'm not even sure there's a right answer to this. I guess I would expect
local variables defined outside of the closure to be accessible within it.
Would that work with DELEGATE_ONLY?

Peter

On Tue, 17 May 2016 at 15:19 Cédric Champeau <cedric.champeau@gmail.com>
wrote:

> As an update, I have made an experiment to automatically generate
> extension methods that do this. It kind of works and reduces the immediate
> need for this. Especially in the context of static compilation. The issue
> is always what to choose as the default delegation strategy. While delegate
> first is often the one used in DSL, I could also see benefit in using
> delegate only in the context of statically generated code...
>
> 2016-05-04 7:46 GMT+02:00 Mario Garcia <mario.ggar@gmail.com>:
>
>> +1
>>
>> 2016-05-03 10:29 GMT+02:00 Jochen Theodorou <blackdrag@gmx.org>:
>>
>>> On 03.05.2016 08:26, Cédric Champeau wrote:
>>> [...]
>>>
>>>> repositories { // Action<? super RepositoryHander
>>>>     maven { Action<? super MavenRepository>
>>>>          url '....'
>>>>     }
>>>> }
>>>>
>>>
>>> I see... I would feel much better if this was done by a special
>>> interface, coming from Groovy... maybe even a trait. But I guess this is
>>> not really an option.
>>>
>>> [...]
>>>
>>> Doing the same for abstract classes should be straightforward. For
>>>> static compilation, it's going to be more complicated and probably
>>>> requires transparently invoking a configurer (like Gradle does).
>>>>
>>>
>>> the proxy generation will work the same, I guess you are talking about
>>> the direct method calls inside the closure as well es letting it pass
>>> static compilation. But I still don't understand what you mean by configurer
>>>
>>> bye Jochen
>>>
>>>
>>>
>>
>

Mime
View raw message