OK, in this specific context: if you use a symbolic ref, it's easier to accidently allow the user access to subs they shouldn't have access to. For example, in a text-based RPG, there's quite likely a win sub, which is called when the user wins. If you use a symbolic-ref based implementation, unless you're careful, the user can simply type "win" to win the game. In a hash-based system, you'd have to explicitly put the win key in the hash, so it's quite unlikely to happen accidently.

OTOH, there might be a 'save' function to save the game, but since you forgot to put 'save' in your hash (or worse, you made a typo), the user can't save.

More likely though is that all the subs dealing with user commands are stored in a different module. And you can do something like:

    while (<>) {
        my ($verb, @args) = split;
        no strict 'refs';
        if (defined &{"Verbs::$verb"}) {"Verb::$verb" -> (@args)}
        else {print "No verb '$verb' implemented.\n"}
    }
[download]

Why one would even want to bother with a hash in between is beyond me.

Abigail

I don't see how the logic you would implement to keep someone from calling the "win" subroutine without being a winner would be any different in a hash than it would be in the subroutine where the winning actually happens. Sure, anyone can say "win" to my interpreter. I just won't be stupid enough to let them think they have won unless they actually have, which is exactly what I'd expect someone to do in the hash based implementation.

You fail to convince me.

-- dug

I don't see how the logic you would implement to keep someone from calling the "win" subroutine without being a winner would be any different in a hash than it would be in the subroutine where the winning actually happens.

Symrefs are much like using global variables. In both cases, the fundamental problem is there's just one symbol table for "everything". You can of course use packages to separate things from one another (and should, if you want to use symrefs), but packages share the same problem symrefs have: package names are global variables... and for them, there's absolutely no way to separate them from one another.

At the end of the day, just like for global variables, it boils down to avoiding them wherever they're not unavoidable. If something doesn't take a disproportionate amount of effort to do with a different method, then it shouldn't be done with symrefs.

In this case, symrefs and a dispatch hash work equally well. Just because of that, you should habitually use the dispatch hash. Could you logically argue that a 10 line script (and I don't mean illegibly compressed code) must be written under strict? Unlikely. Would you do it anyway? Most likely. It's just the same here.

Makeshifts last the longest.

Hm. In your code, you have to explicitly exclude the subs, or put them in a different pacakge. In a hash-based implementation, you have to explicltly put the subref in the hash.

Consider that the "back of the envelope" code with the hash-based dispatch table does this kind of checking implicltly, whereas the symref code doesn't do it at all.

---

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).