Acme-CPANModules-Import-CPANRatings-User-davidgaramond
view release on metacpan or search on metacpan
Nice interface (the analogy to File::Find certainly helps) and very
straightforward to use, but one thing I can't do is modify the data
inplace. I spent about an of hours trying to make Data::Walk do
inplace modification, but finally gave up and use Data::Rmap
instead.
Rating: 8/10
Data::Transformer
Author: BALDUR <https://metacpan.org/author/BALDUR>
Frankly, I don't like the interface. I suspect most people would
like to just specify one callback function instead of one for each
type. Also I don't like having to work with $$_ ($_ should perhaps
be aliased to the real data). As the Data::Transformer's POD also
said, those looking for alternatives can checkout Data::Walk and
Data::Rmap, which I recommend instead. <br>
Rating: 4/10
Data::Traverse
Author: FRIEDO <https://metacpan.org/author/FRIEDO>
I find the interface rather unintuitive, because I expect data to be
in $_ (instead of type). For those looking for alternatives, see
also Data::Walk (which provides breadth-first as well as
depth-first) and Data::Rmap (which provides inplace modification).
<br>
Rating: 4/10
Regexp::Grammars
Author: DCONWAY <https://metacpan.org/author/DCONWAY>
Parse::RecDescent is dead. Long live Regexp::Grammars! <br><br>As
Damian himself has said/presented, RG is the successor for the
popular PRD. <br><br>The docs of RG is not as complete (yet) as
PRD's. <br><br>The PRD grammar syntax is also nicer/cleaner (due to
RG having some restrictions because you are writing your grammar
inside a regex). <br><br>RG doesn't (yet) have some of the features
of PRD, like <leftop> and <rightop>. But it does have
most of the features, and add a few of its own. <br><br>RG performs
significantly faster than PRD. <br><br>In general, whenever you
consider PRD to be a good candidate of tool to solve your problem,
consider using RG. <br><br>But you need Perl 5.10+ to use RG, as it
depends on regex features not found in older Perl. <br>
Rating: 8/10
Parse::RecDescent
Author: JTBRAUN <https://metacpan.org/author/JTBRAUN>
Responding to previous comment from MB: "Have you the time to
do this Damian?" The answer is yes, in the form of
Regexp::Grammars, which Damian said himself is the successor of
Parse::RecDescent. <br><br>To give credit to this module, PRD is
very featureful and easy to use, it's very convenient to generate
parsers, and the docs is quite complete. The only problem with it
is, as many have pointed out, speed. <br><br>It is *seriously* slow,
with parser generation can take up to half a second on my laptop
with a moderate grammar (200-400 lines) and parsing can take seconds
even minutes for a moderately long string. It is orders of magnitude
slower than other parsers. Do think a few times before deciding you
can take the performance hit of PRD. <br><br>For alternatives, try
Regexp::Grammars. (Or Parse::Yapp or Parse::EYapp, as other
reviewers have written.)
Rating: 6/10
Test::Seperate
Sorry, just commenting the name, shouldn't it be Separate?
File::Size
Author: OFER <https://metacpan.org/author/OFER>
Frankly I prefer the name and interface of Filesys::DiskUsage.
Sadly, despite the docs mentioning "blocks", this module
doesn't really count block usage like the Unix "du"
command, because it doesn't take multiple hard links into account.
<br><br>Even more sadly, Filesys::DiskUsage doesn't either.
<br><br>I guess I'll have to do with 'system "du $file"'
command for now. <br>
Rating: 4/10
DateTime
Author: DROLSKY <https://metacpan.org/author/DROLSKY>
*THE* definitive date/time handling module in Perl (and even maybe
in all major programming languages). Can't believe I went through
all the pain of reinventing the wheel, and using various date/time
modules of various quality & interface. If only I had known
DateTime earlier. <br><br>Look no more, DateTime it is. <br>
Data::Rx
Author: RJBS <https://metacpan.org/author/RJBS>
I've been mulling over writing this kind of module (planning to call
it Schema::Nested or something), but never got around to do it.
Thankfully somebody stepped up and did it! Keep up the good work,
will be looking forward to future releases (especially i'm hoping
for some subclassing mechanism, for better reuse of schemas). <br>
DBI::Mysqlsimple
I agree with the previous reviewer. IMO, overall this module is not
necessary. Plain DBI is actually simple enough for simple cases.
Maybe the author of Mysqlsimple did not realize this. Let's compare:
<br><br>* Retrieving a single row: <br> Mysqlsimple: my ($v1,$v2) =
$db->get_row("select v1,v2 from table"); <br> DBI: my
($v1, $v2) = $dbh->selectrow_array("select v1,v2 from
table"); <br><br>* Retrieving a single row (with params): <br>
Mysqlsimple: my ($v1,$v2) = $db->get_row("select v1,v2 from
table where cond1=? and cond2=?", [$cond1,$cond2]); <br> DBI:
my ($v1,$v2) = $db->selectrow_array("select v1,v2 from table
where cond1=? and cond2=?", {}, $cond1,$cond2); <br><br>*
Retrieving all rows with params: <br> Mysqlsimple: my $rows =
$db->get_rows(..., [$param1, $param2]); <br> DBI: my $rows =
$dbh->selectall_arrayref(..., {}, $param1, $param2); <br><br>*
do() with params: <br> Mysqlsimple: my $rows = $db->do(...,
[$param1, $param2]); <br> DBI: my $rows = $dbh->do(..., {},
$param1, $param2); <br><br>As you can see, the differences are
( run in 1.077 second using v1.01-cache-2.11-cpan-5a3173703d6 )