Hm. You avoid cholera and get the pest. Not a good deal. I'd rather avoid creating and destroying an anonymous sub each time through a loop - so I'd write that as
{
my $subs = {
num => sub { $a <=> $b },
cmp => sub { $a cmp $b },
};
for ( qw{ NS MX TXT HINFO SPF SRV A CNAME PTR } ) {
if ( exists $dns_records{$_} ) {
print_header("$_");
my $sortby = $subs->{ uc $_ eq 'PTR' ? 'num' : 'cmp' };
for my $rec ( sort { $sortby->() } @{$dns_records{$_}} ) {
print $rec, "\n";
}
}
}
}
even if the optimizer would save my ass... | [reply]
[d/l] |
"isn't really a closure.."
Exactly, even though it technically is a real closure. The unnamed sub will remember the value of $type as long as the sub exists (in that sense it is a closure). But since $type isn't used anywhere in the unnamed sub, it is of no consequence.
| [reply] |
Actually that is not quite right. If a variable is not visibly used in a returned subroutine, Perl cleans it up. You can verify that with this example:
sub create_closure {
my $x = "x";
my $y = "y";
return sub {
$y .= "y";
eval q{print "x: $x\ny: $y\n"};
};
}
create_closure()->();
And you will find that $x is not properly remembered, but $y is. | [reply]
[d/l] |
Interesting fact of the disturbing kind ;-)
The language designer or a programmer in that language would still call it a closure. That the implementation optimized it away would (normally) only interest the implementor of the language. That it can be revealed through an eval I would call an implementation bug. Ideally any optimization must not change the result of a programm execution.
| [reply] |
How fancy you need to get is really a performance issue. The sort function takes in pairs of whatever the input list is, could be a list of anything. You provide a function that compares those "things".
sort @array, use perl $a cmp $b criteria for sort
sort {} @array, anon sub to provide decision function, returns <0,0,>0.
sort myorder @array. myorder is a sub that provides same <0,0,>0 return values.
Sticking some decision making inside the comparison function is not out of the question. I have an application that sorts some GUI columns. So I made a text or numeric comparison function so the low level's don't have to know what the data type is. This simplified the code. Most columns are alpha and this extra test in the compare really doesn't slow things down much - actually in this app, insignificant amount although my extra testing "looks" expensive. There is a fair amount of overhead in calling the comparison function but some easy "if" logic once you are there is not that expensive (your mileage may vary). Anyway I would consider embedding your test for "PTR" into the a mysortfunc. test it and see if there is any significant difference. There is no need for: return sub { $a cmp $b }, the sub you are writing is the thing that will return <0,0,>0! Don't call an anon sub within your sub. Just get on with the job of returning the required value.
Oh, below I checked both $a and $b as there is some possibility of data corruption in this app. In your case, this appears to be unnecessary, just check one of them. Anyway, look at performance and you may find that something easier works very well.
sub alpha_num_cmp {
my($a, $b) = @_;
if (( $a =~ m/\D/) || ($b =~ m/\D/) )
{ #look for a non-digit
return ($a cmp $b); #string compare
}
return ($a <=> $b); #straight numeric comparison
}
#used like: sort alpha_num_cmp @array;
| [reply]
[d/l] |