Quote:Original post by smr
Seems complicated (of course everything in java seems too complicated to me ;P). Something like this would be cool (I don't know if this would work. I'm not a java programmer):

*** Source Snippet Removed ***

delegate void ClickDelegate();class X {    public event ClickDelegate Click;}class Y {    public void OnClick() { /*do stuff*/ }}void settingItUp() {    X x = new X();    Y y = new Y();    x.Click += new ClickDelegate(y.OnClick);}

Quote:Original post by Barius
I don't really see how signals/slots are useful in Java. I haven't used them, but it seems to me that they are mainly useful in a language that makes it painful to use observer classes, because those
a) need to be defined at a separate location in the code, making the code hard to follow
b) need to be initialized explicitly with "context variables" (what objects to call methods on, etc)
But in Java, you can use anonymous inner classes, which can be used in-place and capture their context automatically - they are effectively closures.

Quote:Original post by Barius

Quote:Original post by Emmanuel Deloget
Signal/slot and observers are totally different beasts, and they are used to solve different problems. Basically, you use an observer when you want to emphasis on the fact that an update is needed, while the signal/slot mecanism puts an emphasis on the treatment itself and on the fact that it is possible to modify the dynamically change the treatment.

"Totally different beasts"? IMO, they are just two types of event handling mechanisms that both try to decouple the sender from the receiver - with signals/slots, the sender of the signal does not know to which slots it goes, and what those slots do. With observers, the "sender" has a list of receivers (observers) and calls a method on each, but does not know what those methods do.
And you can dynamically add/remove observers from those lists, too.

Maybe our ideas of what an Observer is are different? I thought that classes implementing Java's MouseListener, ActionListener, ... interfaces were observers, because they observe what happens to the GUI (that a button is clicked, etc.)

Quote:Original post by Barius

Quote:Original post by Emmanuel Deloget
Moreover, signals are typically functions or methods while the observer's update function is inherited from a base class.

Java doesn't have an easy way to use "free" methods/functions as first-class objects - using the reflection API to get at a method just feels inelegant, clunky and error-prone (because you throw compile-time checks out of the window) to me. Using anonymous classes implementing an interface is much easier.
That why I just don't see any benefits to using signals/slots in Java (compared to languages without anonymous classes or delegates or closures, like C++).