|
in reply to Re: A more elegant way to filter a nested hash?
in thread A more elegant way to filter a nested hash?
Why is this getting so much up votes. People still advertising how to slice hashes using map and grep when the Perl language has more elegant ways to slice hashes.
use strict ;
use warnings ;
use Data::Dumper ;
my $source = {
f1 => 'garbage',
f2 => 'more garbage',
f3 => 'important data',
f4 => {
this => 'sub hash',
is => 'garbage'
},
f5 => {
f6 => 'more important data',
f7 => {
more => 'garbage',
f8 => 'important data',
},
f9 => 'garbage',
},
f10 => [ 'important', 'data' ],
f11 => [ 'more', 'garbage' ]
};
my $filter = {
f3 => 1,
f5 => {
f6 => 1,
f7 => {
f8 => 1
}
},
f10 => 1
};
sub sliceTheWholeDarnThing {
my $s = $_[0] ;
my $f = $_[1] ;
my $n = {} ;
my @keysToGet = keys %{ $f } ;
@{ $n }{ @keysToGet } = @{ $s }{ @keysToGet } ;
foreach ( keys %{ $n } ) {
if ( ref $n->{ $_ } eq 'HASH' ) {
$n->{ $_ } = sliceTheWholeDarnThing( $s->{ $_ }, $f->{ $_
+} ) ;
}
}
return $n ;
}
my $newHash = sliceTheWholeDarnThing( $source, $filter ) ;
print Dumper( $newHash ) ;
|
Re^3: A more elegant way to filter a nested hash?
by shmem (Chancellor) on May 31, 2018 at 22:20 UTC
|
Why is this getting so much up votes.
Reasons may include:
- first answer
- pointing out that foreach or map/grep are essentially the same thing (seee below)
- telling the OP that a working and readable solution is enough
- eating my own dog food by not writing too much (but see below)
Hash slices are syntactic sugar for iterating over a set of keys. I'd suspect the code path for both being identical (see B, do benchmarks with a meaningful set). Elegance is in the eye of the beholder.
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply] |
|
|
Excuse me, but what you are calling syntactic sugar, I call grammar!. Actually I find your comment diminishing towards all those fantastic computer linguistics that have been working so hard to incorporate iterative behaviors into the natural language of Perl. Choosing long used idioms over major parts of the grammar is your choice but personally I feel you are staying one step behind. Take Perl 6 for example where they are taking these concepts even a 1000 steps further!
Just doing a bit of googling, finding tons of examples. This one from the perl6 archives is already from 2000:
The ability to take an indexed slice of a hash is desired. This would allow the programmer to pare out several keys and values from hash A into a new hash B, for greatest flexibility. Currently, this is only available through map():
%other = map { $_ => $sounds->{$_} } qw(lizard duck);
Which could be simplified to:
%other = slice(%$sounds, { qw(lizard duck) }); # or,
%other = (%$sounds =~ sl/lizard duck/h); # or,
%other = %$sounds->{'lizard', 'duck'}; # or,
%other = %{$sounds}{ qw(lizard duck) }; # trad'l
Syntactic sugar? Sure, whatever.
edit: corrected typo, changed last comment. | [reply]
[d/l]
[select] |
|
|
Actually I find your comment diminishing towards all those fantastic computer linguistics that have been working so hard to incorporate iterative behaviors into the natural language of Perl.
Excuse me, syntactic sugar is in no way diminishing nor pejorative. It is sweet! I love it! It enables me to write things this or that way as I see fit for the task, conciseness, readability and so on, and it is one of the major strengths of perl.
I have demonstrated that the OPs foreach loop can be rewritten in terms of map and grep, and the internal code path is the same - the very definition of syntactic sugar. Nothing bad about that.
But my major point is: having a working solution means "job done" in the first iteration; improvement can be done into various directions (performance, readability, maintainability, conciseness, exploring grammar, to mention a few) and each has its place and merits.
Hash slicing is sweet - I use it all the time. But in the case of the OP, there's evaluating the sliced hash values at the moment the slice is done involved, so the examples you presented don't fit.
Furthermore, when programming, I am dumb or pretend to be so, because, as the saying goes
Debugging a program is more difficult than writing it in the first place. Therefore, if you write your program as smart as you are, you are, by definition, too dumb to debug it.
I have been clubbed to death by my cow-orkers for using the Highlander List Asserter for populating hashes
my %hash = (
foo => 'bar',
(baz => $quux) x!! $quux, # list repitition, see "x" in perlop
);
and they accused me of writing unreadable code and shunned me as a developer. They insisted in that particular piece to be written as
my %hash = (
foo => 'bar',
);
if ($quux) {
$hash{baz} = $quux;
}
because nobody groks what x!! means. Silly, in my eyes, because once you see that construct, as strange as it may look, and reading the comment and reading perlop, you know what it does and won't forget it. Ah well...
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
| [reply]
[d/l]
[select] |
|
|
|
|
| [reply]
[d/l]
[select] |
Re^3: A more elegant way to filter a nested hash?
by jimpudar (Pilgrim) on May 31, 2018 at 20:45 UTC
|
Thanks for the input!
I do agree this is quite a bit more elegant. Hash slicing is very nicely suited to this problem.
I will need to put together a set of test cases for this function anyways, so I will try out all the versions posted so far and report back on the Benchmark results.
Best,
Jim
πάντων χρημάτων μέτρον έστιν άνθρωπος.
| [reply] |
Re^3: A more elegant way to filter a nested hash?
by LanX (Saint) on May 31, 2018 at 18:34 UTC
|
I had the same idea, but you are effectively iterating twice over the keys if you slice first.
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
|
|
|
|
|
|
|
