From: Daniel Amelang <daniel.amelang@...>
Date: 2005-07-20T08:16:15+09:00
Subject: Re: ] Re: Ruby has ruined my Java (was Re: Ruby has ruined my C++)

> We could even wrap that in a method to make the syntax cleaner. With a
> clean syntax, we can even switch out what the actions are based on
> runtime times without ugliness. Looking good. But there are still two
> more objections which lead me to suggest a dispatcher model: shared
> actions and multiple actions tied to the same event. Neither of these
> work very well if at all without a stored proc/dispatch model.

+1000 Yes! I spent _months_ playing with the 'dispatch directly
through method' approach and came to the same conclusion for the same
reasons. It is very 'cool', but becomes inflexible very quickly. I
guess with AOP techniques, you could get the multiple action thing,
but it's just not as easy and how are you going to delete actions
easily? Reorder? Ug.

 Right now I'm playing with a publish-subscribe model for
communicating between widgets. In this scenario, system events,
inter-widget events and direct events (calling button.push explicitly)
are all just messages handled by a very small pubsub core contained in
each widget. Essencially, just a fancy dispatcher :)

Dan