|
Re: Nested Dispatch Tables?
by chromatic (Archbishop) on Mar 24, 2008 at 04:43 UTC
|
I was wondering: is there a way to write nested dispatch tables, so that I can dispatch based on the type as well?
That sounds like polymorphism to me. Call a named method on a container instance or an object instance and Perl will dispatch to the appropriate method for you based on type.
| [reply] |
Re: Nested Dispatch Tables?
by bobf (Monsignor) on Mar 24, 2008 at 04:48 UTC
|
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.
| [reply]
[d/l]
[select] |
|
|
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?
| [reply]
[d/l]
[select] |
|
|
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,
},
};
| [reply]
[d/l] |
|
|
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.
Julio
| [reply]
[d/l]
[select] |
Re: Nested Dispatch Tables?
by NetWallah (Canon) on Mar 24, 2008 at 05:24 UTC
|
If you are doing OO programming, the need for dispatch tables outside a class should not arise. Or, rather, if it does arise, the decision should be delegated to the appropriate (sub)class, and have only one dimension.
To my mind, if requirements appear more convoluted than that, the objects have not been sufficiently decomposed. In particular, when you appear to need to dispatch by TYPE - that decision clearly should already have been done based on the class of the object you are addressing.
Perhaps, if you gave us some information about the problem domain (preferably code or pseudo-code), this discussion would not appear to be so abstract.
"As you get older three things happen. The first is your memory goes, and I can't remember the other two... "
- Sir Norman Wisdom
| [reply] |
|
|
| [reply] |
Re: Nested Dispatch Tables?
by sundialsvc4 (Abbot) on Mar 24, 2008 at 15:45 UTC
|
Ditum Ne Agas: Do Not Do A Thing Already Done.
What you are describing is “a RESTful application,” and there's no good reason to do that yet again. It's already been done. And, done well. Look at things like Catalyst and other existing Perl frameworks which you might be able to apply to your goals.
Programmers “instinctively” jump to the conclusion that they must write a new application, but let's face it: ain't too much really new in this world, and there's no point in doing yet-again what has already been done. Just hitch a ride on a passing starship and go.
“I don't want to invent a warp engine! I want to get to Alpha Centauri in time for dinner!”
| [reply] |
|
|
At the core of it, the RESTful interface isn't the overarching goal - it's just a single piece of a larger entity. It doesn't make sense to me to use an entire framework when all I need is a dispatch table. The URL rewriting example was simply to explain that different types/actions would be getting passed to my script.
| [reply] |
