in reply to Command line tool coding style?

That's clever, though you should wrap the method call in an eval block or check can to prevent catastrophic failure if someone asks for an undefined action. Generally I use a dispatch table (hash) of subrefs, but this also works.

(You can safely omit either -w or warnings, and you don't need srand if you're using a Perl with the warnings pragma.)

Replies are listed 'Best First'.
Re^2: Command line tool coding style?
by Aristotle (Chancellor) on Jan 16, 2002 at 05:34 UTC

    If you look closer, you'll see there is indeed a can $execute $_action up at the top..

    I was going to go with the dispatch table hash approach originally, but what irked me was that I had to put either the entire subroutine code above the body of the main program (when what I wanted is to put them below), or write this => \&do_this hash entries which means maintaining an extra list - neither of which I found satisfactory. After looking at my switch-like construct long and hard enough I noticed I had a bunch of veiled method calls.. hence this was the "natural" solution.

    Are you sure warnings will do an srand for me? (It is a left-over I forgot to remove from the actual script for this example - there's some password generation in there.) I'd be very surprised if it did..

[reply]
      I did indeed miss can in my first couple of reads.

      This isn't how I'd usually do things, but I'm warming to the approach. It does beat maintaining an extra list and it's prettier than autogenerating a list of methods from the symbol table.

      The warnings pragma will not call srand for you, but any version of Perl recent enough to have that pragma will automatically call srand when necessary. They're not related, and 5.5.3 (without warnings) does call srand automatically. I should have explained it that way initially.

[reply]

In Section Seekers of Perl Wisdom