in reply to Subclassing a class that uses an internal dispatch table

Email the author and ask why? That seems like an awful lot of work for what was probably a misapprehension on the author's part.

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
  • Comment on Re: Subclassing a class that uses an internal dispatch table

Replies are listed 'Best First'.
Re^2: Subclassing a class that uses an internal dispatch table
by BrowserUk (Patriarch) on Oct 30, 2007 at 19:12 UTC

    That's an interesting take on the problem. Using a dispatch table is the archetypal "best practice" for implementing externally derived, command driven dispatching, so I guess the question then becomes:

    How would you implement a dispatch table within a class so that the dispatched code can be overridden?

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      We already have one. It's called the Perl dispatcher.
      # Sanitize $cmd here if you want. Maybe you go against a list of a +cceptable # commands that's accessible via $self->add_command( 'cmd1' ); my $method = $self->can( $cmd ); $self->$method( @args ) if $method;
      Is there something I'm missing? This is very similar to what SQL::Parser does and it's pretty successful.

      My criteria for good software:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?