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 [email protected]:
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/
