in reply to Nested Dispatch Tables?

You can use any structure as a dispatch table (although they may not all fit the formal definition), including a HoH ($dispatch{$type}{$action} = $sub). A regular hash would work if you decided upon a method for concatenating params into a single string to use as a key ($dispatch{ $type . '_' . $action }).

Perhaps I do not understand what you mean by a 'nested' dispatch table. Please elaborate if I'm missing the question.

Replies are listed 'Best First'.
Re^2: Nested Dispatch Tables?
by Spidy (Chaplain) on Mar 24, 2008 at 16:22 UTC

    That sort of sounds like what I'm looking for. In the end, I want to be able to make a call like $actions->{$type}->{$action}->();, or however you'd accomplish the same thing(if that makes any sense) in actually valid Perl.

    This isn't the most elegant of solutions, but would building my two dispatch tables(something like %objects and %containers) and then storing them into an %actions hash as references work?

      The code you give there is valid Perl. If you built a structure using something like the following you would be able to use it just like that:
      my $actions = { first_action => { type1 => \&some_function, another_type => \&another_function }, second_action => { another_type => \&function, yet_another_type => \&something, }, };
      -- David Irving

      Altough you have said that you are not using object-oriented techniques, what chromatic gave you reads like this: $container->action() or $object->action() which looks quite elegant to me. Instead of dispatch tables, you would have two classes and then choose what kind of object to create depending on your $type variable. Then, for each class, you would have your special $actions (methods). That way your main code is the same for both containers and objects, and their differences are hidden in their own space.