[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: idea of vision of blueprint of ROADMAP of Lua core
- From: David Jones <drj@...>
- Date: Wed, 19 Jan 2005 11:34:35 +0000
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;
look at the Adaptor debacle for an example. And heaven help you if you
to provide two different callbacks that have the same name.
Closures are definitely the way to go for this sort of thing. They
*so* much easier... the GUI system we're implementing where I work is
written in C++, which doesn't have closures, and uses function
instead. These are fine for standalone applications, but not terribly
friendly for objects; you have to implement a static function that
callback's user pointer to the appropriate type and calls a method on
However, function callbacks do have the advantage of being very
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
This is possible due to Objective-C's highly cool and reflexive