groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Henry <christo...@c-henry.fr>
Subject Re: Fwd: Proposition on a simple implementation of event-driven programming in Groovy.
Date Sat, 06 Jun 2015 20:31:03 GMT
Hello,

As I'm not sure everybody follows the github repo, I'm posting again my 
question here. My (tiny) contribution looks ok to me, now. I've added 
unit tests and documentation but I'd like to go further. As I wrote in 
my comment, I'd like to find a way to constraint parameters of the 
closure from what the user would pass to the constructor, like this:

Event event = new Event(variable1: int, variable2: String)

And then, it'd be possible for a user to use these declared variable 
directly in an anonymous Closure declaration, like this :

event << {
     int var = variable1
     variable2.each{ print it }
}

Would this be possible ?

On 26/04/2015 15:09, Christophe Henry wrote:
>
>
>
>
>
>
> That's it. Basically, this is a simplified implementation of the
> observer pattern. But I am asking myself some question about the
> implementation. E.g : should the sender of the event be accessible
> to the subscribers ? Or isn't it a bit dangerous to let the event to
> be called from outside the sender ? I see that the @Bindable AST
> produces public fireXXX methods. So maybe my
> current implementation 
> <https://github.com/apache/incubator-groovy/pull/4/files> would be valid ?
>
>
>
> On 26/04/2015 13:58, Paul King wrote:
>
>
>>
>>
>>
>>
>> Perhaps a first start might be to look at the AST transforms for
>> ActionEvents:
>>
>>
>>
>>
>>
>>
>>
>> http://docs.groovy-lang.org/docs/groovy-latest/html/documentation/#_swing_patterns
>>
>>
>>
>>
>>
>>
>>
>> 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
>>
>>
>>
>> class.
>>
>>
>>
>>
>>
>>
>>
>> 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 types.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Le 23 avril 2015 00:52:37 GMT-11:00, Jochen Theodorou
>>>> <blackdrag@gmx.org> a écrit :
>>>>
>>>>
>>>>
>>>>> Am 24.04.2015 02:28, schrieb CH:
>>>>>
>>>>>
>>>>>
>>>>>> Sorry, what is a GEP ?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Groovy Enhancement Process (GEP)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> http://docs.codehaus.org/display/GroovyJSR/GEP+1+-+Groovy+Enhancement+Proposal
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 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: http://blackdragsview.blogspot.com/
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ---
>>
>>
>>
>> This email has been checked for viruses by Avast antivirus
>> software.
>>
>>
>>
>> http://www.avast.com
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
> -- 
>
> /Cordialement,
>
> Christophe Henry/
>
>
>
>
>
>
>
>


-- 
/Cordialement,
Christophe Henry/


Mime
View raw message