in reply to Re: Event based programming: Callbacks or "Interfaces"?
in thread Event based programming: Callbacks or "Interfaces"?

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.

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

Replies are listed 'Best First'.
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.