groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Fwd: Proposition on a simple implementation of event-driven programming in Groovy.
Date Thu, 23 Apr 2015 10:48:09 GMT
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/


Mime
View raw message