On 7/19/05, Michal 'hramrach' Suchanek <hramrach / centrum.cz> wrote:
> On Tue, Jul 19, 2005 at 06:55:23AM +0900, Jacob Fugal wrote:
> > On 7/18/05, Daniel Amelang <daniel.amelang / gmail.com> wrote:
> > > ...
> > > button.when_pushed do
> > >   puts "Hey, don't push my buttons!"
> > > end
> > > ...
> >
> > I, personally, would prefer something more along the lines:
> >
> > button.on_event( :push ) do
> >   puts "Hey, don't push my buttons!"
> > end
> 
> This looks like it is more flexible .. but it requires the user of the
> library to write a dispatcher function. And since ruby is dynamic you do
> not need to force users into writing dispatchers to get flexibility.

First, the user doesn't have to write the dispatcher, that's provided
by the library. You mention in a followup that you were confused, so
I'll forgive you for that ;) I know I get confused quite often :)

However, you do bring up a good point: since ruby is dynamic you
shouldn't need to write dispatchers. Why can't I just do this:

class MyButton < Button
  # override what happens on a push, then simply have windowing code
  # call methods, rather than sending events
  def push
    puts "Don't push my buttons!"
  end
end

button = MyButton.new
button.push

First off, as has been mentioned in another thread, inheritance just
to define new events isn't really the best idea. Ok, easy to fix:

button = Button.new
class << button
  def push
    puts "Don't push my buttons!"
  end
end
button.push

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.

Jacob Fugal