+1 this seems like a great idea.
Graeme
On Wed, May 18, 2016 at 9:11 AM, Jochen Theodorou wrote:
On 18.05.2016 08:46, Peter Ledbrook wrote:
> 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. Wou
On 18.05.2016 08:46, Peter Ledbrook wrote:
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?
yes, static scoping is done by the compiler, before any runtime can
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
wrote:
> As an update, I have made an experiment to automati
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
+1
2016-05-03 10:29 GMT+02:00 Jochen Theodorou :
> On 03.05.2016 08:26, Cédric Champeau wrote:
> [...]
>
>> repositories { // Action> maven { Action
>> url ''
>> }
>> }
>>
>
> I see... I would feel much better if this was done by a special interface,
> coming from Groovy... m
On 03.05.2016 08:26, Cédric Champeau wrote:
[...]
repositories { // Action
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 ab
2016-05-02 18:11 GMT+02:00 Jochen Theodorou :
> On 02.05.2016 16:44, Cédric Champeau wrote:
> [...]
>
>> Of course, it may look a bit superficial but it is super important for
>> nice DSLs like in Gradle.
>>
>
> could you give an example of a more complex closure usage?
>
Sure, basically you can
On 02.05.2016 16:44, Cédric Champeau wrote:
[...]
Of course, it may look a bit superficial but it is super important for
nice DSLs like in Gradle.
could you give an example of a more complex closure usage?
We should be also aware that this change may break code, since it is
semantic change an
On Mon, May 2, 2016 at 5:25 PM, Joe Wolf wrote:
> [...]
>
> [Hi, all. This is my first post to the list--been a happy Groovy user
> since version 1.5]
>
Welcome here and thanks for using Groovy since 1.5!!! :-)
Guillaume
>
> -Joe
>
>
> On Mon, May 2, 2016 at 10:56 AM, Guillaume Laforge
> wro
+1
Would it be sensible/possible to add a Closure.FIRST_ARGUMENT resolve
strategy and include it in the default resolution chain? The 'it'-less
closure would behave as expected even without pre-assigning the delegate
(provided that length() was not defined by the delegate/owner). It'd still
probab
+1
On Mon, May 2, 2016 at 4:44 PM, Cédric Champeau
wrote:
> Hi guys,
>
> I've been grumpy about this for a bit too long to keep it for myself, so
> let me explain the issue :)
>
> Imagine you have a Java method that accepts a SAM type:
>
> interface Action {
>void execute(T object)
> }
>
> c
11 matches
Mail list logo
