in reply to Munging with a regex dispatch table

slightly offtopic, but have you condsidered cleaning up your regexp list as such: 
my %REGEX = (
    header    = qr/^(?!START:|END:)([^*: ][^:]+):(.+)\n/,
    starttime = qr/^START:\s*(.+)\n/,
    endtime   = qr/^END:\s*(.+)\n/,
    lineitem  = qr/^(?:\* |  )([^:]+):(\d+):(.+)\n/,
);

[download]

then you call it as: $REGEX{'header'}

functionally its identical, but when editing code later on, i find it way easier to see whats going on

Replies are listed 'Best First'.
Re^2: Munging with a regex dispatch table
by Anonymous Monk on Feb 02, 2005 at 03:04 UTC
    It's not the same thing. He's using the regex as a key with the corresponding code/action as the value to that key. He could write: 
    my %REGEX = (
    header    = [qr/^(?!START:|END:)([^*: ][^:]+):(.+)\n/, \&header],
    starttime = [qr/^START:\s*(.+)\n/, \&etc],
    endtime   = [qr/^END:\s*(.+)\n/, \&etc],
    lineitem  = [qr/^(?:\* |  )([^:]+):(\d+):(.+)\n/, \&etc]
);
#...
#You could even use constants here to make things easier.
# 0 = RE; 1 = FUNCTION; or something.
for my $rex_table (keys %REGEX) {
  if (my @m = $line =~ $rex_table->[0]) {
    $rex_table->[1]->($r,@m);
    next LINE;
  }
}

    [download]
    Which I, personally, think is preferable. The implementation of the dispatch table depends really on implementation. I like to have the name of the action as a 'key', so that the code's self-documenting, but you could also use the array aproach previously shown.
[reply]
[d/l]

      No doubt that this is an improvement over the original. But I think that someone should point out the negatives of this as well. First, to reiterate the positive: IMO, this table is much better than the original, if only to eliminate the qr from the keys. But it also keeps the regexp close to the function that it dispatches to.

      However, I would not recommend this dispatch table for a couple of reasons.

      First, it's not really a table. Dispatch tables are called tables for a reason, I think. HoA is not a table - although AoH is a table (with named columns), and AoA is a table (with numbered columns). If you were to add another field which was some sort of ordering that could be used to sort the keys, then your HoA would be a column (with ordered/orderable rows).

      I prefer names to the columns. Makes things easier to see. Also makes things easier to modify. And thus easier to maintain. Better than constants since the "column" names are in the structure, not external to it. Which is easier to read: 

        [
    qr/^(?!START:|END:)([^*: ][^:]+):(.+)\n/,
    \&header
  ]

      [download]
      ... or ... 
        {
    re => qr/^(?!START:|END:)([^*: ][^:]+):(.+)\n/,
    action => \&header
  }

      [download]
      Somewhat of a tossup. Now, let's add four more items (columns) to the table. Or, given 10 rows, let's add an optional item to half of them. Those hashes are flexible. Use 'em.

      I'm not really convinced that the keys you have here are really very useful - we don't do a quick lookup of a particular entry, and we don't really use them for anything else. They could really be named a, b, 12, and fourty_two, and nothing would change. (Well, you may get a different pseudo-random order from keys. But that could change just by changing perl versions...) Here an array makes much more sense.

      Oh - and you're missing the >'s in each entry - should be header => ... ;-)

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom