lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Jan 18, 2005, at 10:30, David Given wrote:

On Tuesday 18 January 2005 02:42, Chris Pressey wrote:
At any rate, the class that one writes that implements ActionListener
doesn't have to implement anything besides actionPerformed, and for
conceptual integrity of the design, probably shouldn't.  So it still
ends up being a "closure in object's clothing".

Absolutely. Java's EventListeners can only be described as half-assed; just look at the Adaptor debacle for an example. And heaven help you if you need
to provide two different callbacks that have the same name.

Closures are definitely the way to go for this sort of thing. They make life *so* much easier... the GUI system we're implementing where I work is mostly written in C++, which doesn't have closures, and uses function callbacks
instead. These are fine for standalone applications, but not terribly
friendly for objects; you have to implement a static function that casts the callback's user pointer to the appropriate type and calls a method on that. However, function callbacks do have the advantage of being very lightweight
and customisable.

What does C# do? And Objective-C?

As I understand it, and I am _not_ an Objective-C expert, you generally provide an object that implements a particular protocol. In Objective-C any object can implement any protocol (regardless of its class) this seems to be quite a good way of proceeding.

For example Mac OS X provides an NSSound class. To see when a sound has finished playing you set the sound's delegate to your delegate object using the setDelegate: method of NSSound. When the sound has finished playing the delegate's sound:didFinishPlaying: method gets called.

This is possible due to Objective-C's highly cool and reflexive run-time system.

David Jones