Reviews by mirod


Module-Mask (0.03) *****

What can I say, it works. I don't need it often, but when I do it is much easier to use than to muck with @INC myself.

You need to keep the mask object in scope while creating it before using the module you want to mask, so I used it this way:

use Module::Mask;

my $mask;

BEGIN { $mask = Module::Mask->new('My::Module'); }

use My::Module;

DBIx-Simple (1.32) *****

Great module.

It takes care of a lot of the tedious code you have to write to use DBI. The method names needed to access the results are easy to remember, and it delegates very sensibly common tasks, like creating HTML tables from the results, to other modules.

I am not really into ORM, I prefer to write the SQL myself, and this is the best module I've found for this. Basically its interface is what DBI's should be (which of course is easier to figure out now than when DBI was written).

XML-Bare (0.27) *

This module uses the XML namespace but it is NOT an XML parser:

- it doesn't support mixed content
- it allows unquoted attributes
- it supports only 1 comment per node

There seem to be more restrictions to what the parser supports, but it is hard to figure them out. As it is, it obviously both supports non-well-formed XML, and doesn't support properly some well-formed XML. Further tests would be needed to figure out exactly how the format it supports overlaps with the official XML spec.

It is quite easy to write a fast quasi-XML parser. It is a LOT more difficult, but a lot more useful, to write a real, spec-compliant parser.

I hope one day this module becomes a real XML module. As of version 0.27 it seems to bit a bit far from that goal.

This is not it at the moment.

XML-XPath (1.13) *

This review applies to XML::XPath 1.13, released in January 2003.

The module has not been maintained in a long time (close to 5
years) and there are a number of open bug reports (some with patches
that have not been applied in 2 years).

XML::LibXML is most likely a better choice, if you can install libxml2.
It's basic interface is very, very similar to XML::XPath, but the module is faster, much more powerful and actively maintained.

Acme-Pasty (0.01) ***

Just to correct slightly the 2 previous reviews, the "website" being pumped up ( is not a real one , so I would indeed consider this a proper (if only mildly funny) use of the Acme namespace.

File-Find-Rule (0.28) *****

I have always used File::Find and found it quite easy to use. But I must say that my first attempt at using File::Find::Rule has convinced me!

It is really easy to use and very powerful too.

It took me 3 lines to emulate quite closely how grep looks for file!

Image-Size (2.992) *****

Does one thing and does it well. Very easy to install and to use. If you need more you can use Image::Magick.

Devel-Cover (0.34) *****


The easiest way to get feedback on your test and to figure out how good they are and how to improve them. It gives you the figures for statement, branch, condition, subroutines and pod coverage, plus a commented version of the code showing the coverage.

The SYNOPSYS gives you all you need to know about it.

A must-use module

File-Slurp (2004.0904) *****

A few convenient functions that help uncluttering your code when you need to read (or write) an entire file into (or from) a scalar or an array.

Of course you could write them yourself, but why? They are in File::Slurp, use them.

The version number is quite surprising: I had never seen a module with a date as the version number, much less a date in the future.

Note that an other module, Slurp, which I have never used, seems to do quite the same thing, in a slightly different way: it lets you slurp several files in a single scalar, array or array_ref, but doesn't have functions to write to a file.

YAML (0.35) *****

Overall a very useful module, both for debugging complex data structures and for serializing data, such as configuration options.

I use YAML everywhere I used to use Data::Dumper. Its format is more compact and easier to read than Data::Dumper's. It is also more secure, as you reload the data using a function, and not 'do'. I also tend to use it for configuration files, over XML::Simple: it's more compact, easier to use (no complex configuration options) and to read.

I still can't write a YAML file, but I find it very easy to edit.

Lastly, I found INGY pretty responsive to change suggestions.

Acme-JAPH (0.03) ****

I thought it was funny

XML-PYX (0.07) ****

I like XML::PYX. For me PYX is like a poor man's SAX: a very simple stream interface to an XML document. I find it simpler to use than SAX, and I like the fact that it is line-oriented. Processing line-oriented data is something that Perl is designed to do, and that Perl programers are usually familiar with.

The module is pretty simple and stable. In fact I never use it as a module, but rather use the ools it comes with: 'pyx' to get the PYX flow for an XML document, and 'pyxw' to output the XML from a PYX flow. Note that you can also use 'pyxhtml' to get the PYX flow for an HTML document.

Of course the PYX model is very simple and does not cover all of the XML spec (comments are lost, there is no namespace processing...) so it won't work in all cases. Nevertheless it is really useful when you just want to extract data from a document, and generally for all sorts of simple XML processing.

DBD-SQLite (0.26) *****

DBD::SQLite gives you the power of a relational database, without the hassle of having to actually administrate it: the modules comes with the data base library nad a data base is stored into a single file. Which means that the install is as simple as typing "i DBD::SQLite" in CPANPLUS, and the administration consists in setting the right permissions on the file. Backups can be done using cp.

I use it for log analysis, data mining... basically every time I would previously have used a big flat text file. It gives me the power of SQL and the speed of database.

I only use it in single user mode though, my attempts at doing concurrent access were not too successful (that was a while ago though, so it might be fixed now).

XML-DOM (1.43) **

XML::DOM implements the W3C DOM (Document Object Model) level 1.

While the module is a proper implementation of the standard, IMHO the DOM is really not a great choice for generic XML processing. It is very low-level and often leads to brittle, if not outright buggy, code. It is also very verbose.

XML::LibXML is a much better choice: it also implements the DOM, amongst other standards, but it is much more powerful. Most notably its XPath engine makes the code a lot safer (and shorter). Porting code from XML::DOM to XML::LibXML seems to be quite easy BTW. XML::GDOME can also be used instead of XML::DOM.

XML::DOM is also quite old, and not actively supported, although the maintainer must be thanked for taking care of a module that he does not really use.

To be fair XML::DOM is also quite popular and pretty stable.

Inline-Files (0.62) *****

Inline::Files is really cool: it extends the __DATA__ concept to
other names. You can then have a __FOO__ section, and a __BAR__
section, that you will access just like you would access the
__DATA__section: through the FOO and BAR filehandles.

The filehandles can even be opened in write mode, and, provided your code has write access to itself, it will just update the data in the proper section (you might want to use the "backup" option though, just in case something goes wrong in your code ;--)

I really like Inline::Files because it lets me package data with my code, even when I would need several files: CGI scripts can include the associated templates, test files can include the test data, DB management code can include the database definition... This is a much nicer alternative to heredocs.

Text::Template / Text-Template (1.44) *****

There are (way too!) many templating systems on CPAN, but IMHO none of them is as simple and as elegant as Text::Template.
Text::Template just lets you include Perl code in a file or a string. Include Perl code between { } and it will be executed and the return value will replace the code fragment. Extra features include a way to change the delimiters, a special variable that gather the output, error handling, a safe mode and the option to refer to variables from your code, from a hash or from a specific namespace.
This will let you generate plain text, but also HTML, XML... any text-based format really.
The drawback of this approach is that it is probably not recommended to give a template that includes too much Perl to a graphic designer. OTOH a template maintainer who already knows Perl does not have to learn a new templating language, and can use all of the power of Perl.