Re^2: A short, "iffy" rant

That can still be easily solved with a dispatch table.

    sub _select_fields
    {
        my $self = shift;
        my %rev_types = (
            both    => sub { 
                # some difficult logic
            },
            total   => sub { [qw/foo bar/] },
        );

        my $rev_type = $self->request->param('rev_type');
        $rev_type    = 'both' unless exists $rev_types{$rev_type};
        return @{$rev_types{$rev_type}->()};
    }
[download]

Though as noted above, the $rev_types should probably be moved outside of the sub.

If necessary, you can also write some code for generating a hash key based upon the difficult logic. This has the advantage of cleanly encapsulating the logic for each case rather than embedding it in the if/elsif/else constructs.

Cheers,
Ovid

New address of my CGI Course.

Comment on Re^2: A short, "iffy" rant Download Code

Replies are listed 'Best First'.
Re^3: A short, "iffy" rant by jryan (Vicar) on Oct 11, 2004 at 21:58 UTC
I guess its time to make my standard plug to use Exporter::Dispatch... although this case is probably too simple to warrant the module.	[reply]
Re^4: A short, "iffy" rant by tilly (Archbishop) on Oct 12, 2004 at 05:25 UTC
What problem were you trying to address when you wrote this? My feeling is that for the effort of creating a new package (likely in its own file), and importing a module, you get to write `sub foo {...}` rather than `foo => sub {...},` - but I don't see the syntax change as mattering much while I do see that overhead as mattering quite a bit. Furthermore rather than seeing closures as an unnecessary complication, I see them as an opportunity. You can ignore the fact that you can use closures to fill in the table. But if you need it, you have the ability to use closures to autogenerate large portions of your dispatch table. And a further hash advantage - you are allowed names that would not easy or (in some cases) legal in Perl function names.	[reply] [d/l] [select]
Re^5: A short, "iffy" rant by jryan (Vicar) on Oct 18, 2004 at 00:19 UTC
What problem were you trying to address when you wrote this? Modularity, Maintenance - the usual suspects. Exporter::Dispatch isn't really aimed at dispatch tables of 3 or 4 subs of 1 line a piece - its aimed for use with large dispatch tables. For instance, the last time I used it was on a project with 4 dispatch tables, each having between 10-30 subroutines, with each subroutine varying in length from 10-60 lines. As for closing over lexical variables, you can still do that if the subs are in a separate package - you just put the declaration in the same package as the rest of the dispatch table subs are defined! But, as for: And a further hash advantage - you are allowed names that would not easy or (in some cases) legal in Perl function names. What does that buy you? The only time I think I've ever used a dispatch table that had non-word dispatch names was this: `my %op_table = ( '+' => sub { $_[0] + $_[1] }, '-' => sub { $_[0] - $_[1] }, '' => sub { $_[0] $_[1] }, '>' => sub { $_[0] > $_[1] }, '<' => sub { $_[0] < $_[1] }, '=' => sub { $_[0] == $_[1] }, # this is the one oddball; # otherwise i could just eval'ed.. +. '<=' => sub { $_[0] <= $_[1] }, '>=' => sub { $_[0] >= $_[1] }, '!=' => sub { $_[0] != $_[1] }, );` [download] This was part of a very simple simulator that I wrote for a language that we have compiled down to 68HC11, and the only reason I wrote it this way was so I could use the raw token as the hash key.	[reply] [d/l]
Re^6: A short, "iffy" rant by tilly (Archbishop) on Oct 18, 2004 at 16:14 UTC


Keep It Simple, Stupid
	PerlMonks