> Then why create a list from the hash in the first place?
It's meant to be compatible with the standard interface!
You might remember that map, sort and grep can be chained and they always accept and return lists...
| [reply] [d/l] [select] |
You might remember that map, sort and grep can be chained and they always accept and return lists...
Hm. Passing a listified hash (mixed keys and values in random order) to any of those constructs is a completely pointless exercise.
That is after all, why you are having to define an hgrep yourself.
Better methinks to pass hgrep and hmap a reference to the hash, call the callback with pairs, and have them return a list.
At least then they serve a purpose:
#! perl -slw
use strict;
use Data::Dump qw[ pp ];
sub hgrep (&\%) {
my( $code, $href ) = @_;
map{
local @_;
$code->( @_ = each %$href ) ? @_ : ()
} 1 .. keys %$href;
}
sub hmap (&\%) {
my( $code, $href ) = @_;
map{
local @_;
$code->( @_ = each %$href )
} 1 .. keys %$href;
}
my %h = 'a'..'z';
print join ' ', hgrep{ $_[0] =~ /[a-m]/ } %h;
print join ' ', hmap{ "$_[0] => $_[1]" } %h;
my %orig = (
cat => 22,
dog => 23,
category => 66,
catalyst => 77,
cataclysm => 88,
dogma => 89,
dogstar => 92,
);
my %h2 = hgrep{ $_[0] =~ /^cat/ } %orig;
pp\%h2;
__END__
C:\test>hfp
e f a b m n c d k l g h i j
w => x e => f a => b m => n s => t y => z u => v c => d k => l q => r
+g => h i => j o => p
{ cat => 22, cataclysm => 88, catalyst => 77, category => 66 }
hsort is left as an exercise.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] [d/l] |
BrowserUk: Your implementation of hmap and hgrep is a little tricky, but I certainly wouldn't describe it as 'quite obfuscated'! However...
sub hmap (&\%) {
my( $code, $href ) = @_;
map{
local @_;
$code->( @_ = each %$href )
} 1 .. keys %$href;
}
In the code above, I don't see the point of local-izing @_ and then assigning each to it. Passing the return of each %$href 'directly' to the coderef seems to work just as well.
>perl -wMstrict -MData::Dump -le
"sub hmap (&\%) {
my( $code, $href ) = @_;
map{
$code->(each %$href)
} 1 .. keys %$href;
}
;;
my %h = 'a'..'z';
;;
print join ' ', hmap { qq{$_[0] => $_[1]} } %h;
;;
my %orig = (
cat => 22,
dog => 23,
category => 66,
catalyst => 77,
cataclysm => 88,
dogma => 89,
dogstar => 92,
);
my %h2 = hmap { $_[0], $_[1] + $_[1] } %orig;
dd \%h2;
"
w => x e => f a => b m => n s => t y => z u => v c => d k => l q => r
+g => h i => j o => p
{
cat => 44,
cataclysm => 176,
catalyst => 154,
category => 132,
dog => 46,
dogma => 178,
dogstar => 184,
}
| [reply] [d/l] [select] |
> > It's meant to be compatible with the standard interface!
This can't be chained at least not easily w/o more transformations in the middle.
your input is a hashref your output a list ...
and your code is quite obfuscated...
... though ++ for creative use of each within map.
| [reply] [d/l] [select] |