tl;dr version: Is it better for event handlers to have one method per type of event? Or one method to accept all events? Or something else?
Currently event handlers (called EventWatchers) in Test::Builder2 implement two methods: accept_event and accept_result. accept_result() is a special case to handle results (which are special events) and accept_event() takes care of everything else. This means you wind up writing stuff like: my %event_dispatch = ( "stream start" => "accept_stream_start", "stream end" => "accept_stream_end", "set plan" => "accept_set_plan", "log" => "accept_log", ); sub accept_event { my $self = shift; my($event, $ec) = @_; my $type = $event->event_type; my $method = $event_dispatch{$type}; return unless $method; $self->$method($event, $ec); return; } Which isn't too bad, but it seems like make-work. The alternative is for the event handlers to have a method for each event, (ie. accept_stream_start, etc...) falling back to accept_event if there is no specific handler. my $method = type2method($event->event_type); $handler->can($method) ? $handler->$method($event) : $handler->accept_event($method); I chose a single method for all events for two reasons: 1) Speed. The event coordinator doesn't have to call can() on every handler and every event. 2) It makes it easy to write a handler that slurps up all events, like the History object. It turns out #1 can be made moot with some careful programming. #2 can be handled by falling back to a generic handler. So now the question is one of good event handler design, which I don't have experience with. How does one design a good event handler? Is the pattern one method per type of event? Or one method to do the dispatching? Or something else? -- Being faith-based doesn't trump reality. -- Bruce Sterling