Re^2: Munging with a regex dispatch table

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.

Comment on Re^2: Munging with a regex dispatch table Download Code

Replies are listed 'Best First'.
Re^3: Munging with a regex dispatch table by Tanktalus (Canon) on Feb 02, 2005 at 05:15 UTC
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]

Replies are listed 'Best First'.

Re^3: Munging with a regex dispatch table
by Tanktalus (Canon) on Feb 02, 2005 at 05:15 UTC

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]

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

flexible

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]