Hi!
I don't really see the point of using delegates in java. The code with ActionListeners is more clear to me than using some function pointer, and passing them into UI elements. It implements observer/obesrvable pattern, and it's more objective for me than delegates... You can easily implement your won calls that will implement this pattern just by having a list of objects that implemet some interface and invoking it's method, nothing more....
And when I saw how my collegue tries to implemet his won delegates in C# it was very difficult to me to understand what his trying to do (he also didn't know it... :D )

Have a nice day

Oh, another suggestion is to use a more Microsoft alike approach. For example when instead of:

container.add(button)

the following is writen:

container.add(SwingEventDispatcher.wrap(button, "store", this));

This line still adds the button to the container, but also names the button "store" and binds it to "this" by searching for methods with a particular pattern, for example:

public void store_actionPerformed(ActionEvent e)

Note the "store_" prefix. To make the source more readable this method may also be written as:

public void store_clicked(ActionEvent e)

And some intelligence is added also:

public void store_singleClick(ActionEvent e)
public void store_doubleClick(ActionEvent e)
public void store_tripleClick(ActionEvent e)
public void store_multiClick(ActionEvent e)

It makes sure that on a double click only xxx_doubleClick is called and not xxx_singleClick also.

The same trick works with all events:

mybean_propertyChanged(PropertyChangeEvent e)
mylist_selectionChanged(...)
...

A cleaner solution (IMHO) are closures. Using closures would result in something like:

JButton button = new JButton();
button.addActionListener() { e | button.setText("bla"); }

Closures basically are inner classes that can access its context without having to use final (the local variable button is used in the inner class). Groovy provides a (hopefully soon) standard way to do this, but at least Groovy is fully Java compatible.

Maybe I'm not following the argument here, but I guess I wonder why someone would prefer to pass around function pointers rather than interfaces. Can't the dispatch code just as easily invoke a method through an interface as through a Delegate class?

I guess I am uncomfortable with the modularity here. First of all, actual implementation classes have a sort of rigidity from the standpoint of the client and the programmer. So I like having interfaces anyway. But the other issue is that a method may start out being 'standalone', but then it may need to be called as part of a sequence of other methods. If you delegate through Interfaces, then it would seem you could add those other methods very easily.

Finally, variable argument lists are prone to incorrect use in all circumstances; but in this one there is no commonalties among the arguments. The classic 'printf' variety of variable argument lists was very clear -- each of the variable arguments is intended to be rendered as text. In this case it can be results of embedded function calls or anything. I guess I don't understand why one would want to suppress type checking.

Anyway I have really not gotten the idea or the benefit of this technique. Sometimes it's worthwhile to emulate one language's constructs in another language, but I don't see it here.

There's nothing wrong with inner classes per se; they represent a superset of the functionality of delegates or method pointers. The problem is the Java language itself, and the lack of lightweight anonymous function/class declaration, and the lack the type inferencing. Fix those two things and the ugly part of inner classes (the declaration syntax) goes away.

Scala does lightweight functional syntax very nicely. If func takes something like an action listener, you can call it like this (for arrow read greater-equals):

func(event "arrow" event.getComponent().setSelected(true));

Scala knows the expected type for the call and builds the scaffolding necessary. Under the covers you end up with:

func(new ActionListener() {
public void actionPerformed(Event event) {
event.getComponent().setSelected(true)
}});

The Buoy package contains some things similar to what you've outlined in your article. Although I have not worked with, reading the examples makes it appear that your goals of making the event handling code easier exists already in Buoy.

One of the things I miss the most about C is the lack of pointers to functions. Used correctly, these are fantastically useful. Hopefully, some of that can be added back (or implemented as is shown here) for the greater good of all.

Remember too, the 'Evil Empire' did not invent this desire (as noted by a previous respondent) they only implemented a shortcoming that they saw. This is not a bad thing.

### Dennis Farr commented ...
Great article. I have been haunted by the thought that not all differences between C# and Java were abberations, and your article shows how to take advantage of the good ideas coming out of the evil empire and use them inside Java. ###

The idea is certain to provoke widepsread discussion - it reminds how close C# and Java are.

Great article. I have been haunted by the thought that not all differences between C# and Java were abberations, and your article shows how to take advantage of the good ideas coming out of the evil empire and use them inside Java. Java is at least open enough to discuss and use ideas from outside Sun, as I hope yours will be.