in reply to Re: Re: Naming Subs
in thread Naming Subs

Symbolic references are loaded with caveats. If you know them and know to avoid them, you're fine, of course.

Dispatch hashes are still better. A hash is a portable namespace. Using a dispatch hash promotes separation between disjunct parts of your application's logic: in this case, the hash encapsulates the game logic, while the toplevel code handles the user input logistics.

Not to mention that just understanding that you can "store subs in a hash" is a large conceptual step that will open up an entire world of new possibilities.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Re^3: Naming Subs
by dug (Chaplain) on Jan 13, 2003 at 04:11 UTC
    Symbolic references are loaded with caveats. If you know them and know to avoid them, you're fine, of course.

    Or if you know how to use them, of course :-)

    Dispatch hashes are still better. A hash is a portable namespace. Using a dispatch hash promotes separation between disjunct parts of your application's logic: in this case, the hash encapsulates the game logic, while the toplevel code handles the user input logistics.

    I am still not convinced that game and user logic need to be separated in *this* particular case, which is why I'm arguing that my posted method *may* be a more maintainable method.

    Not to mention that just understanding that you can "store subs in a hash" islarge conceptual step that will open up an entire world of new possibilities.

    Ahh, this is good. This is educational for new Perl hackers, which is exactly what is needed. Which is what I'm arguing. I hope that's what folks see in this thread.

    Thanks, Aristotle

    -- dug
[reply]

      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.

      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).

[reply]
        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

[reply]
[d/l]
        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
[reply]

In Section Seekers of Perl Wisdom