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