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