On 2011.10.27 12:36 AM, chromatic wrote:
> I've done this several times. I prefer one method per type of event (hello,
> cheap and easy polymorphism!).
Yeah, that's my thinking. One method for all makes overriding next to
impossible.
> This is also one case in which I find an abstract base class acceptable; the
> null method pattern means never having to call ->can().
I would agree, but the set of possible events is not finite. New events will
be added in the future, and it's actually kosher for users to define their own
events. It would suck if older watchers vomited and stopped the whole test
for an event it didn't care about.
I'd considered adding an AUTOLOAD to make null methods... but yeah. It also
makes it difficult to trap all events, as History has to do. It would have to
know about and override AUTOLOAD. Bleh.
PS The performance spread we're talking about is in the 10-20% range. That's
discounting anything the watcher might DO with the event, so in practice it
will be negligible. Multiple event handlers with a fallback to accept_event()
is the slowest, but arguably the best design.
--
184. When operating a military vehicle I may *not* attempt something
"I saw in a cartoon".
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/list/
