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.

Hm. In your code, you have to explicitly exclude the subs, or put them in a different pacakge.

No, I was saying that I wouldn't be dumb enough to let a loser win by saying "win" to my interpreter. That hasn't changed.

In a hash-based implementation, you have to explicltly put the subref in the hash.

You are saying that you wouldn't allow anyone to win until you installed the "win" subroutine reference into the oh-so-huge hash in your script? That's interesting.

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.

I don't know what this "back of the envelope" code that you speak of is.

-- dug

I believe the point he's trying to make is that you have to explicitly disallow subroutines that you don't want the user to be able to access directly from the interface. With the hash based inplementation, you have to explicitly allow a user to call a sub directly from the interface. Generally, a whitelist is much easier to maintain than a blacklist, with fewer reprecussions if you make an error when adding or deleting subs (i.e. if you forget to allow a sub the user needs it is less of a problem than if you forget to disallow a potentially dangerous sub). Consider what happens if the user types in "delete_user_by_name SomeUserIDislike" and it works.

There would be nothing keeping the user from winning in the case of the hash table, it just prevents the user from calling the "win" sub directly; Only the script can call that subroutine so the user must satisfy all the win conditions before they win.

--
Grant me the wisdom to shut my mouth when I don't know what I'm talking about.