groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <>
Subject Re: Fwd: Proposition on a simple implementation of event-driven programming in Groovy.
Date Sun, 26 Apr 2015 11:58:43 GMT

Perhaps a first start might be to look at the AST transforms for ActionEvents:

This will illustrate Java's property change and action events within JavaBeans and
swing programming. And also some Groovy syntactic sugar (@ListenerList, @Bindable)
over the top. I imagine you'll want something similar but for a more generic Event

Cheers, Paul.

On 26/04/2015 7:43 PM, Christophe Henry wrote:
> Does someone would be interrested to work on this with me ? Or guide me on a proposition
? I'm not sure the way I should implement this feature. I mean I have a clear idea of how
it should work, how the user should use it, but beyond that, I'm don't have clear ideas. Maybe
someone with more experience on Groovy could help me to draft the principles of this feature
> /Cordialement,
> Christophe Henry/
> On 24/04/2015 03:04, CH wrote:
>> Thank you. I just thought that a GEP would have been a good thing because the way
this feature has to work is not completely clear for me. E.g : I didn't think about the way
to pass the sender of an event to the closures or the way to constraint the closures parameter
>> Le 23 avril 2015 00:52:37 GMT-11:00, Jochen Theodorou <> a
écrit :
>>> Am 24.04.2015 02:28, schrieb CH:
>>>> Sorry, what is a GEP ?
>>> Groovy Enhancement Process (GEP)
>>>> Do you have some documentation about the testing procedures in the
>>> project so I have something to take as a reference for this work ?
>>> usually we do junit3 style tests using GroovyTestCase for stuff in
>>> core,
>>> like where this would be. At least for API tests. For test of the
>>> language side we usually use assertScript(String) method from the test
>>> case, which allows you to write a small script, including helper
>>> classes
>>> and all in a multiline string
>>>> And finally, do you have rules about the présentation of the code
>>> like curly brackets on a new line or not, etc.?
>>> normally { on the same line (unless it is too long) and spaces between
>>> operators, ident as spaces (4). Everything else usually just works out.
>>> If there is something too terrible looking we will tell you ;)
>>> bye blackdrag
>>> --
>>> Jochen "blackdrag" Theodorou
>>> blog:

This email has been checked for viruses by Avast antivirus software.

View raw message