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

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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."
  • Comment on Re^2: Subclassing a class that uses an internal dispatch table

Replies are listed 'Best First'.
Re^3: Subclassing a class that uses an internal dispatch table
by dragonchild (Archbishop) on Oct 30, 2007 at 19:45 UTC
    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;

    [download]
    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?
[reply]
[d/l]
[reply]
        Nope. Think of it as a hash lookup that is a huge set of hashes looked at in the proper order.
        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?
[reply]

In Section Seekers of Perl Wisdom