Re: idea of vision of blueprint of ROADMAP of Lua core

[David Jones <drj@...>]

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