Re: Event based programming: Callbacks or "Interfaces"?

Both styles result in a function getting called, but that function is determined in different ways

explicitly named
resolved through a hierarchy

I think that the flexibility afforded by the interface style is by far a more effective technique.

An interface can change at runtime, whole new classes of behaviour can easily be brought to bear with just a few keystrokes, etc, technique much harder to achieve through static coderef's.

+++++++++++++++++
#!/usr/bin/perl
use warnings;use strict;use brain;

Comment on Re: Event based programming: Callbacks or "Interfaces"?

Replies are listed 'Best First'.
Re: Re: Event based programming: Callbacks or "Interfaces"? by tilly (Archbishop) on Jun 01, 2004 at 07:37 UTC
I detect someone who doesn't appreciate the power of closures. After Why I like functional programming, perhaps you'll appreciate better what you can accomplish with callbacks.	[reply]
Re: Re: Event based programming: Callbacks or "Interfaces"? by dfaure (Chaplain) on Jun 01, 2004 at 09:31 UTC
I think that the flexibility afforded by the interface style is by far a more effective technique. IMHO (using several C++ GUI libraries), it really depends on what you have to provide to your users: Your code offers GUI services for end-user application, You're about to make a complete framework, hiding implementation details. Interface based framework implies exposing the whole framework to the end user application which is tied to it. This also could be problematic with portability requirements. Callback driven framework enables you to have a centralized event handling and to use finite-state machine if required (i.e. the same sub handles all the events of a form and its widgets). The object definition features of the choosen implementation language is also a constraint. Very often, using hierarchy of objects implies needing runtime type information, introspection, persistence,... Things and behaviours which are not always available natively nor easy to implement (I'm thinking of C++ and more generally of all compiled languages). Anyway, the two systems can co-exist... :-) HTH, Dominique	[reply]
Re^2: Event based programming: Callbacks or "Interfaces"? by adrianh (Chancellor) on Jun 01, 2004 at 09:51 UTC
An interface can change at runtime, whole new classes of behaviour can easily be brought to bear with just a few keystrokes, etc, technique much harder to achieve through static coderef's. I don't think this is true myself. With a callback based model it's trivial to produce one-off callbacks without having to create a whole separate class that may be overkill. Closures and anonymous subroutines give you a heck of flexibility at runtime. Personally I would use a class based approach if cutting up the domain into classes made sense (do you have common behaviour where inheritance would make sense, are you creating multiple instantiations of the same sort of objects, etc.) Otherwise callbacks would probably be best.	[reply]
Re: Re^2: Event based programming: Callbacks or "Interfaces"? by hardburn (Abbot) on Jun 01, 2004 at 12:51 UTC
I would use a class based approach if cutting up the domain into classes made sense (do you have common behaviour where inheritance would make sense . . . Otherwise callbacks would probably be best. Except that you probably won't get to choose. The decision will be forced on you by the GUI toolkit you use. I suppose you could write a glue layer to transfer between the two styles, but the added complexity may not be worth it. ---- send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.	[reply]