sub sort_maker {
  my @subs = @_;
  sub {
    foreach my $sub (@subs) {
      my $result = $sub->(); # you use $a and $b in your littlesubs - 
+no need to pass in globals.
      return $result if $result;
    }
  }
}

my $sorter = sort_maker(
        sub { lc($data{$a}[0]) cmp lc($data{$b}[0]) },
        sub { lc($data{$a}[1]) cmp lc($data{$b}[1]) },
     );
@results = sort $mysortref (keys %data);
[download]

It's left as an excersise to the reader on how to convert your query language into perl sort functions. Translation: I'd help further, but I don't know how you know what order to sort in.

Translating your code slightly into my style, I'm now working with this:
Read more... (651 Bytes)

It's left as an excersise to the reader on how to convert your query language into perl sort functions. Translation: I'd help further, but I don't know how you know what order to sort in.

Let me explain the context and interface desired. Returning to my original data sample will be illustrative. Suppose that I have data stored in plain-text files, one record per line, fields delimited by whitespace:

Read more... (738 Bytes)

Suppose further that the columns in this table may be named:

    lastname
    firstname
    cno
    unit
    ward
    dateadmission
    datebirth
[download]

And suppose further that I have a hash (probably stashed in a configuration file) which associates those column names with array elements specifying the order and type of searches to be conducted on each column (i.e., ascending or descending order; alphabetical, ASCII-betical or numerical type). That hash might look like this:

  my %parameters = (
    lastname       => [ qw( U a ) ],
    firstname      => [ qw( U a ) ],
    cno            => [ qw( U n ) ],
    unit           => [ qw( U s ) ],
    ward           => [ qw( U n ) ],
    dateadmission  => [ qw( D a ) ],
    datebirth      => [ qw( D a ) ],
  );
[download]

... where U and D are up and down; a, s and n are the 3 search types.

Assuming that the data and the column parameters have been used to initialize an object $dp, I want the user to be able to call a method:

    my $results_ref = 
        $dp->sort_by_column( qw{ lastname firstname cno } );
[download]

... and have $results_ref hold an array of arrays where the outer array is sorted in the order specified in the arguments to sort_by_column. That is, the method will sort the data in the order and using the search-type specified by the column name.

Under normal circumstances, the user (a cron job or a keyboard operator) will run the same script with the same method calls and arguments every day. But from time to time the database administrator will have to prepare new queries in which, for example, the dates have to be reported in ascending order, rather than descending as in the above. The administrator would then prepare a different %parameters, but the method call would either not change or change so little that the keyboard operator could modify it easily.

In short, the objective is to go from a list of column names to an array of sort formulas each represented by an anonymous subroutine. If lastname is the first column in the table, then "Sort by last names, alphabetically and in ascending order," should translate into:

    sub { lc($data{$a}[0]) cmp lc($data{$b}[0]) },
[download]

The question, then, is how to effect that translation. Thank you very much.

Jim Keenan

Update: Corrected 'readmore' error.

All depends on how abstract you want to get. Given that you want "the keyboard operator [to be able to] modify it easily," I'd say that you may want it as abstract as possible.

Read more... (4 kB)

As you notice, much of the error checking (that parms are actually allowed - e.g., 'foo' isn't a table header) is missing. Feel free to add.

Also, rather than a big hash, you could build it up using an eval STRING. Up to you - I'm using a large closure instead to probably reduce memory, probably reduce runtime, and definitely reduce the ability for me to screw it up security-wise. That said, I do think that this is probably a scenario that could be made secure for an eval STRING, especially if you start getting many more options on how to do things and those start combining to give exponential degrees of freedom. Here there are only six possible comparators, which is easy enough to hardcode ahead of time. More generically, an eval STRING may ease development and maintenance.

Don't put hard-coded subs in @littlesubs. Build up that array dynamically from a bunch of subroutines you've already defined.