RSS | Module Info | Add a review of

DBI-Mysqlsimple (0.02)

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:

* Retrieving a single row:
Mysqlsimple: my ($v1,$v2) = $db->get_row("select v1,v2 from table");
DBI: my ($v1, $v2) = $dbh->selectrow_array("select v1,v2 from table");

* Retrieving a single row (with params):
Mysqlsimple: my ($v1,$v2) = $db->get_row("select v1,v2 from table where cond1=? and cond2=?", [$cond1,$cond2]);
DBI: my ($v1,$v2) = $db->selectrow_array("select v1,v2 from table where cond1=? and cond2=?", {}, $cond1,$cond2);

* Retrieving all rows with params:
Mysqlsimple: my $rows = $db->get_rows(..., [$param1, $param2]);
DBI: my $rows = $dbh->selectall_arrayref(..., {}, $param1, $param2);

* do() with params:
Mysqlsimple: my $rows = $db->do(..., [$param1, $param2]);
DBI: my $rows = $dbh->do(..., {}, $param1, $param2);

As you can see, the differences are minimal.

David Garamond - 2008-05-03 20:46:28
Was this review helpful to you?  Yes No

Carp-Always (0.09)

Modules like this deserve to be more well-known and should perhaps included in core Perl (or even become a command-line switch). I'm never comfortable with Carp and all the "complexity" of using it. What I wanted is simple, when debugging I want all die()'s (and perhaps warn() too, but much less often) to print a stack trace.

Call me inflicted with Ruby- or Python-envy, but it's been so ridiculous wanting to print out stack traces in Perl. I don't want to have to change/rewrite all my die()'s to croak() or confess()! And what about library codes which use die()?

Thank God somebody wrote Carp::Always.

David Garamond - 2008-02-15 18:41:17
Was this review helpful to you?  Yes No

Data-Dump (1.08)

I've envied Ruby users which can use just "p" to print out data structures instead of us which used to have to do 'use Data::Dumper; print Dumper(...);'. And even then there's this '$VAR1 = ' garbage which 99% of the time is not wanted. Which often makes me wonder, shouldn't P in Perl stand for Practical?

With Data::Dump we're still a bit behind but closer. One rant is the with the doc: the pp() function should perhaps be advertised more prominently, since I suspect that's what most users want most of the time.

David Garamond - 2007-12-06 03:02:17
Was this review helpful to you?  Yes No

V (0.13)

What a nice little module. It is by far the easiest to review ;-)

I have been using my own little script called "pmversion" which serves the same exact purpose. I guess I'll be using V from this moment on. It's amazing doing something as basic as showing a module's version had not been this easy or even easier.

David Garamond - 2007-11-17 08:30:20
Was this review helpful to you?  Yes No

Test-Unit (0.25)

Test::Unit is of course a fine module. But if you are shopping around for testing framework, I recommend you try Test::Class instead, which combines the best of two worlds. First, you get xUnit style, but I think with a slightly simpler interface. Second, you get to use all the standard Perl testing stuffs like Test::Simple, Test::More and Test::Harness. This is better because it's what most Perl modules use (so you might be more familiar with it if you're a Perl programmer), plus there are more kinds of "assert" functions in Test::More and friends compared to Test::Unit::Assert.

David Garamond - 2007-11-17 03:47:49
Was this review helpful to you?  Yes No

Module-Build (0.2808)

Here's the short story: first there's Exutils::MakeMaker, which requires make and hard to extend, but everybody uses it due to lack of alternatives. Then came Module::Build which is pure perl and easier to use for authors, but breaks compatibility. Users can no longer use the 'perl Makefile.PL && make && make install' mantra. Plus, it used to not support PREFIX. Plus, MB-based modules require MB which is not by default installed. This pisses *a lot* of people.

Lesson to learn: maintaining backward-compatibility is very important, especially for end users. I think the intention of MB is a good one, but the execution could be a bit better. For example, perhaps the "Build.PL" script could've still just been named "Makefile.PL", couldn't it?

I recommend people shopping for a module installer to look at Module::Install instead. MI is a middle ground between Eu::MM and MB. It's pure perl and easy to extend but it also allows users (and CPAN.pm et al) to install modules the old way. It embeds a copy of itself in every MI-based modules, so there's no depedency hell. Best of both worlds.

David Garamond - 2007-11-09 19:10:58
Was this review helpful to you?  Yes No

YAML-LibYAML (0.26)

It's about time Perl gets a complete and proper YAML parser. This is it. In the past I've been bitten by a couple of YAML's and YAML::Syck's minor bugs, in addition to several crashes (don't know how they are recently). But using YAML::XS (YAML-LibYAML) I get the feeling, for the first time, of a first class parser comparable in stability and completeness to that in Ruby and Python.

David Garamond - 2007-11-09 15:47:57
Was this review helpful to you?  Yes No

Perl.org sites : bugs | dev | history | jobs | learn | lists | use © Copyright 2002-2008 The Perl Foundation Site Information and Contacts