You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by ch...@c-henry.fr on 2015/04/23 11:04:59 UTC
Fwd: Proposition on a simple implementation of event-driven
programming in Groovy.
Hi there,
I have submitted a pull request [1] on github today to propose a simple
implementation for an event feature for Groovy. Here is a short
summerize of what I've written on github:
The feature is inspired from C#'s Event Handler [2] feature syntax and
aims to be very similar to Qt's signals and slots feature to exchange
messages between objects in an event-driven programming style. This is
an idea I've had while working on an android application written in
Groovy [3].
The idea is to add an Event class that inherits from Closure and
contains a list of closures from subscribed objects. When the event is
sent, which basically correponds to a closure call, every closure in the
subscribers list is called with the given parameters. This is a typical
implementation of the observer pattern with the ease of Groovy.
Here is how the system would work :
// This class has an event to which other objects can subscribe
class ObjectWithEvent{
public Event somethingChanged = new Event()
// In a random function, something happens and we decide to send the
event with a value
public void makeSomething(){
somethingChanged(newValue)
}
}
// This class will observe the event
// In the constructor, we subscribe to the event by giving it a callback
class ObjectListening{
private ObjectWithEvent objectWithEvent
public ObjectListening(){
objectWithEvent.somethingChanged += this.&onSomethingChanged
}
private void onSomethingChanged(int newValue){
// Code here
}
}
C#'s event handlers and Qt's signal/slots are core features of these two
languages. It makess developement very easy when dealing with large
amount of objects that communicate often. Groovy's syntax make it very
easy to implement and I am absolutely willing to work on this.
What do you think about the idea ?
Cordialement,
_Christophe Henry_
Links:
------
[1]
https://github.com/apache/incubator-groovy/pull/4#issuecomment-94856515
[2] https://msdn.microsoft.com/en-us/library/ms366768.aspx
[3] https://github.com/AugierLe42e/Pheobius
Re: Fwd: Proposition on a simple implementation of event-driven programming
in Groovy.
Posted by Christophe Henry <ch...@c-henry.fr>.
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
>>>> <bl...@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/
Re: Fwd: Proposition on a simple implementation of event-driven programming
in Groovy.
Posted by Christophe Henry <ch...@c-henry.fr>.
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
>>> <bl...@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/
Re: Fwd: Proposition on a simple implementation of event-driven programming
in Groovy.
Posted by Paul King <pa...@asert.com.au>.
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 <bl...@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
Re: Fwd: Proposition on a simple implementation of event-driven programming
in Groovy.
Posted by Christophe Henry <ch...@c-henry.fr>.
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 <bl...@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/
Re: Fwd: Proposition on a simple implementation of event-driven programming in Groovy.
Posted by CH <ch...@c-henry.fr>.
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 <bl...@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/
Re: Fwd: Proposition on a simple implementation of event-driven programming
in Groovy.
Posted by Jochen Theodorou <bl...@gmx.org>.
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/
Re: Fwd: Proposition on a simple implementation of event-driven programming in Groovy.
Posted by CH <ch...@c-henry.fr>.
Sorry, what is a 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 ?
And finally, do you have rules about the présentation of the code like curly brackets on a new line or not, etc.?
Anyway, thanks for your feedback.
Le 22 avril 2015 23:48:09 GMT-11:00, Jochen Theodorou <bl...@gmx.org> a écrit :
>Hi,
>
>first code wise... If the only reason as of why you want to have Event
>subclassing Closure is because you then can make it like a method,
>that's not needed. You should be able to just remove the super class
>and
>keep the code as is otherwise. Next your pull request will need some
>tests. They help understanding the feature as well.
>
>And finally... I suggest to use leftShift "<<" instead of plus, then
>you
>don't need to do += - resulting in additional, maybe unwanted
>operations.
>
>Normally I would ask for a GEP to better specify the feature and as a
>preparation for future documentation, but we have not set up something
>for that yet.
>
>Am 23.04.2015 11:04, schrieb christophe@c-henry.fr:
>> Hi there,
>>
>> I have submitted a pull request [1] on github today to propose a
>simple
>> implementation for an event feature for Groovy. Here is a short
>> summerize of what I've written on github:
>>
>> The feature is inspired from C#'s Event Handler [2] feature syntax
>and
>> aims to be very similar to Qt's signals and slots feature to exchange
>> messages between objects in an event-driven programming style. This
>is
>> an idea I've had while working on an android application written in
>> Groovy [3].
>>
>> The idea is to add an Event class that inherits from Closure and
>> contains a list of closures from subscribed objects. When the event
>is
>> sent, which basically correponds to a closure call, every closure in
>the
>> subscribers list is called with the given parameters. This is a
>typical
>> implementation of the observer pattern with the ease of Groovy.
>
>For me this opens a few questions... if we use a list, then what about
>thread safety - do we care? If we care about concurrency it will have
>many implications (QT and C# seem to have at least thought about it).
>Also, should it really be on a per object base, because on the property
>
>level we have already @Bindable. Keeping it as simple as possible would
>
>mean, not thread safe and as is. And I was wondering if this should not
>
>be done using a trait... But lastly... why not use Observable/Observer
>directly?
>
>> Here is how the system would work :
>>
>> // This class has an event to which other objects can subscribe
>> class ObjectWithEvent{
>> public Event somethingChanged = new Event()
>>
>> // In a random function, something happens and we decide to send
>the
>> event with a value
>> public void makeSomething(){
>> somethingChanged(newValue)
>> }
>> }
>>
>> // This class will observe the event
>> // In the constructor, we subscribe to the event by giving it a
>callback
>> class ObjectListening{
>>
>> private ObjectWithEvent objectWithEvent
>>
>> public ObjectListening(){
>> objectWithEvent.somethingChanged += this.&onSomethingChanged
>> }
>>
>> private void onSomethingChanged(int newValue){
>> // Code here
>> }
>> }
>
>Just to show how @Bindable could be used for this:
>
>class ObjectWithEvent {
> @groovy.beans.Bindable somethingChanged
>}
>
>def obj = new ObjectWithEvent()
>def acc = 0
>obj.propertyChange = { evt -> acc += evt.newValue }
>obj.somethingChanged = 1
>obj.somethingChanged = 2
>assert acc == 3
>
>Of course this is using the beans from Java and is a bit more heavy
>than
>your suggestion and involves more objects as well. And of course you
>can
>use methods too... Not saying this is better, just something to look at
>
>when comparing.
>
>And to make it more directly comparable:
>
>class ObjectWithEvent {
> Event somethingChanged = new Event()
> public void makeSomething(newValue){
> somethingChanged(newValue)
> }
>}
>def obj = new ObjectWithEvent()
>def acc = 0
>obj.somethingChanged += { newValue -> acc += newValue }
>obj.makeSomething(1)
>obj.makeSomething(2)
>assert acc == 3
>
>Just to show that the difference is really minimal. And as long as the
>event version does not care about multithreading, it is more
>lightweight. As long as we don't want to change @Bindable, Event could
>have the big advantage of supporting different implementations for if
>we
>care about multithreading after all. Which reminds me of another
>advantage... for Event the implementation mostly stays in Event, while
>@Bindable is adding a load of methods to the class.
>
>> C#'s event handlers and Qt's signal/slots are core features of these
>two
>> languages. It makess developement very easy when dealing with large
>> amount of objects that communicate often. Groovy's syntax make it
>very
>> easy to implement and I am absolutely willing to work on this.
>>
>> What do you think about the idea ?
>>
>> Cordialement,
>> _Christophe Henry_
>>
>> Links:
>> ------
>> [1]
>https://github.com/apache/incubator-groovy/pull/4#issuecomment-94856515
>> [2] https://msdn.microsoft.com/en-us/library/ms366768.aspx
>> [3] https://github.com/AugierLe42e/Pheobius
>
>bye blackdrag
>
>--
>Jochen "blackdrag" Theodorou
>blog: http://blackdragsview.blogspot.com/
Re: Fwd: Proposition on a simple implementation of event-driven programming
in Groovy.
Posted by Jochen Theodorou <bl...@gmx.org>.
Hi,
first code wise... If the only reason as of why you want to have Event
subclassing Closure is because you then can make it like a method,
that's not needed. You should be able to just remove the super class and
keep the code as is otherwise. Next your pull request will need some
tests. They help understanding the feature as well.
And finally... I suggest to use leftShift "<<" instead of plus, then you
don't need to do += - resulting in additional, maybe unwanted operations.
Normally I would ask for a GEP to better specify the feature and as a
preparation for future documentation, but we have not set up something
for that yet.
Am 23.04.2015 11:04, schrieb christophe@c-henry.fr:
> Hi there,
>
> I have submitted a pull request [1] on github today to propose a simple
> implementation for an event feature for Groovy. Here is a short
> summerize of what I've written on github:
>
> The feature is inspired from C#'s Event Handler [2] feature syntax and
> aims to be very similar to Qt's signals and slots feature to exchange
> messages between objects in an event-driven programming style. This is
> an idea I've had while working on an android application written in
> Groovy [3].
>
> The idea is to add an Event class that inherits from Closure and
> contains a list of closures from subscribed objects. When the event is
> sent, which basically correponds to a closure call, every closure in the
> subscribers list is called with the given parameters. This is a typical
> implementation of the observer pattern with the ease of Groovy.
For me this opens a few questions... if we use a list, then what about
thread safety - do we care? If we care about concurrency it will have
many implications (QT and C# seem to have at least thought about it).
Also, should it really be on a per object base, because on the property
level we have already @Bindable. Keeping it as simple as possible would
mean, not thread safe and as is. And I was wondering if this should not
be done using a trait... But lastly... why not use Observable/Observer
directly?
> Here is how the system would work :
>
> // This class has an event to which other objects can subscribe
> class ObjectWithEvent{
> public Event somethingChanged = new Event()
>
> // In a random function, something happens and we decide to send the
> event with a value
> public void makeSomething(){
> somethingChanged(newValue)
> }
> }
>
> // This class will observe the event
> // In the constructor, we subscribe to the event by giving it a callback
> class ObjectListening{
>
> private ObjectWithEvent objectWithEvent
>
> public ObjectListening(){
> objectWithEvent.somethingChanged += this.&onSomethingChanged
> }
>
> private void onSomethingChanged(int newValue){
> // Code here
> }
> }
Just to show how @Bindable could be used for this:
class ObjectWithEvent {
@groovy.beans.Bindable somethingChanged
}
def obj = new ObjectWithEvent()
def acc = 0
obj.propertyChange = { evt -> acc += evt.newValue }
obj.somethingChanged = 1
obj.somethingChanged = 2
assert acc == 3
Of course this is using the beans from Java and is a bit more heavy than
your suggestion and involves more objects as well. And of course you can
use methods too... Not saying this is better, just something to look at
when comparing.
And to make it more directly comparable:
class ObjectWithEvent {
Event somethingChanged = new Event()
public void makeSomething(newValue){
somethingChanged(newValue)
}
}
def obj = new ObjectWithEvent()
def acc = 0
obj.somethingChanged += { newValue -> acc += newValue }
obj.makeSomething(1)
obj.makeSomething(2)
assert acc == 3
Just to show that the difference is really minimal. And as long as the
event version does not care about multithreading, it is more
lightweight. As long as we don't want to change @Bindable, Event could
have the big advantage of supporting different implementations for if we
care about multithreading after all. Which reminds me of another
advantage... for Event the implementation mostly stays in Event, while
@Bindable is adding a load of methods to the class.
> C#'s event handlers and Qt's signal/slots are core features of these two
> languages. It makess developement very easy when dealing with large
> amount of objects that communicate often. Groovy's syntax make it very
> easy to implement and I am absolutely willing to work on this.
>
> What do you think about the idea ?
>
> Cordialement,
> _Christophe Henry_
>
> Links:
> ------
> [1] https://github.com/apache/incubator-groovy/pull/4#issuecomment-94856515
> [2] https://msdn.microsoft.com/en-us/library/ms366768.aspx
> [3] https://github.com/AugierLe42e/Pheobius
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/