Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Automating dispatch tables

by BUU (Prior)
on Apr 16, 2004 at 06:36 UTC ( #345657=perlmeditation: print w/replies, xml ) Need Help??

( I can't take all credit for this, I first saw it demonstrated by someone on perlmonks, but I don't recall where or what the name was )

Consider:
%dispatch = ( foo => \&foo, bar => \&bar, baz => \&baz, qux => \&qux, ); sub foo {} sub bar {} sub baz {} sub qux {} if( exists $dispatch{ $method } ) { $dispatch{$method}->(); }
Versus
package dispatch; sub foo {} sub bar {} sub baz {} sub qux {} package main; if( my $ref = dispatch->can($method) ) { $ref->(); }

Replies are listed 'Best First'.
Re: Automating dispatch tables
by liz (Monsignor) on Apr 16, 2004 at 07:45 UTC
    Nice. However, I don't like the package main, because you can never be certain that that's the original package name (as a code practice, not in this example, obviously).

    I would have written this as:

    { package dispatch; sub foo {} sub bar {} sub baz {} sub qux {} } if( my $ref = dispatch->can($method) ) { $ref->(); }
    This automatically returns the package to the original package after the definition of the dispatch table.

    Liz

      Ah. Clever. I just assumed you would know what package you should be returning to :)
Re: Automating dispatch tables
by davido (Cardinal) on Apr 16, 2004 at 07:58 UTC
    I'm not an expert on any of this, but I'll accept your invitation to meditate out loud.

    Your second example could just as easily be written as follows:

    sub foo {} sub bar {} sub baz {} sub qux {} if ( my $ref = main->can($method) ) { $ref->(); }

    But what your version gains is a new package namespace. This can be a convenient way of giving all of the methods in your "dispatch table" a set of common but private variables to work with. This kind of starts feeling like static variables, except that you can get at them from the outside if you know their names.

    On the other hand, this could be nearly as clearly accomplished by putting the sub declarations in an enclosed lexical scope that executes near the top of your script. Example:

    { sub foo{} sub bar{} sub baz{} sub qux{} } my %dispatch = ( foo => \&foo, bar => \&bar, baz => \&baz, qux => \&qux );

    In this case, the subs have their own lexical scope to play within. Your second method provides a package for the methods to play in. My method provides a lexical scope. You can do a lot of the same things with that, except that the lexically scoped variables aren't as easily accessible from the outside except by the subs declared within that same scope.

    The next issue is the convenience of a hash as a dispatch table. Hash elements can be deleted, placed into other hashes, or handed around all together using a hashref. That's a convenient entity to work with.

    Your second method would be that convenient if it were taken one step further, to the point that the refs were captured into a lexically scoped dispatch hash. But then you're getting into another layer of abstraction. Not a big deal. But helpful if you want the convenience that a hash-based dispatch table can give you.

    A final issue to consider is to weigh the ramifications of UNIVERSAL::can being mostly incompatible with AUTOLOAD. Just be careful there.


    Dave

      Interesting thoughts on the lexical scoping issue, and you're quite correct that a hash can have some advantages. However the main reason I used a different package was simply so you had an easy way of determing which subs were allowed to be called by the dispatch table. If you just define the subs in 'main' you have a potential security flaw, as any sub could be called. (Assuming you were dispatching based on at least mildly untrusted data of course).

      In some cases you do need the power of a hash based dispatch, for instance if you wanted to assign a "security level" required to execute each sub, or complicated things of that nature. But for just doing quick "switch" type dispatches, this way is much faster to type and easier to maintain.
        In some cases you do need the power of a hash based dispatch, for instance if you wanted to assign a "security level" required to execute each sub, or complicated things of that nature. But for just doing quick "switch" type dispatches, this way is much faster to type and easier to maintain.

        Uhhh ... that's not quite right. If you're going to go to all the trouble of actually making a new package and a new file (cause, you might as well make these shareable!), then you'd probably also add a security function somewhere. I would envision something like:

        package dispatch; my %disallowed = ( security => 1, ); sub security { # Handle security here, somehow, returning a boolean. } # Because we're overloading can(), we can easily make it play nicely w +ith AUTOLOAD. sub can { my $proto = shift; my ($method) = @_; return '' if $disallowed{$method}; UNIVERSAL::can($proto, $method); } #### Functions to dispatch to below here --------------- if (dispatch->security( ... ) and my $method = dispatch->can( ... )) { $method->(@args); }

        Now, to correct a misconception - without serious craziness of the Devel:: variety, you cannot access a lexically scoped variable outside its scope. Period, Do Not Pass Go, End Of Story. In other words, it's not an issue. This goes for packages or closures. (That's kinda why they're called "closures".)

        ------
        We are the carpenters and bricklayers of the Information Age.

        Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

Re: Automating dispatch tables
by demerphq (Chancellor) on Apr 16, 2004 at 14:19 UTC

    Actually Chip recently pointed out on p5p that the second one is not the right way to handle this. In reality you are much better off avoiding can() and doing:

    eval { $ref->$method() }; # updated: forgot the $method :-( die $@ if $@ and $@!~/^Undefined subroutine/;

    This is because for all kinds of reasons can() is not 100% safe. For instance if the method needs to be autoloaded can() will return false, but calling the sub wont.

    IMO the first one is also not the greatest way to write that.

    $dispatch{$method}->() if $dispatch{$method};

    ---
    demerphq

      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi


Re: Automating dispatch tables
by kappa (Chaplain) on Apr 16, 2004 at 07:22 UTC
    First thought: this won't work (or will be ugly) when the events we are going to handle with this dispatch table look weird, for example non-english words, punctuation marks or something like that.
Re: Automating dispatch tables
by blakem (Monsignor) on Apr 16, 2004 at 09:49 UTC
    Hmmm... that would break on a couple specific cases... like when $method is 'can' or 'VERSION' for example.

    -Blake

Re: Automating dispatch tables
by jryan (Vicar) on Apr 16, 2004 at 23:24 UTC
Re: Automating dispatch tables
by QwertyD (Pilgrim) on Apr 19, 2004 at 04:36 UTC

    Hm... interesting idea. The main point seems to be unifying the sub declarations and the dispatch table. In the first example, you declare subs, then create a dispatch table for them, then dispatch. In the second, you declare subs, and essentially use the symbol table as a dispatch table.

    You could also do the opposite, which is to create the subs as part of the dispatch table:

    my %dispatch = ( foo => sub {}, bar => sub {}, baz => sub {}, qux => sub {}, ); if( exists $dispatch{ $method } ) { $dispatch{$method}->(); } );

    Or am I missing the point?
    (It's entirely possible. I should be asleep right now.)


    Once it's Turing complete, everything else is just syntactic sugar.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://345657]
Approved by kvale
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (3)
As of 2020-10-25 09:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My favourite web site is:












    Results (249 votes). Check out past polls.

    Notices?