Supposedly this was written to be faster and fix some api niggles in the venerable File::Slurp. But the documentation doesn't even mention any of this. And it doesn't even try to maintain any compatibility with the majority of the File::Slurp api that was perfectly fine. So I'll stick with the original File::Slurp for ease of use over the minor performance gain and annoying api changes of this one.
This is specifialized tool specific to linux, and the namespace chosen is inappropriately generic. This should be renamed to something like Linux::sparse or similar. It should also specify during the build phase that linux is required, using something like Devel::AssertOS.
Whenever I need to do a lot of complicated image processing, I use Image::Magick; simpler stuff I typically use Imager. Although GraphicsMagick claims to be superior to ImageMagick, they're perl support is lacking. One of the developers claims that the GraphicsMagick module "is one of the most complicated PERL modules in existence" and therefore will never be submitted to CPAN:
The stated rationale for this module is to have a version of Object::Tiny with writable accessors. The author apparently didn't bother to do any research as that is the purpose of Object::Tiny::RW. There are many, many reviews of the the different worthwhile class builders. This low rating is intended to steer new users away from a pointlessly reinvented wheel and to seek a more widely used (hence vetted) module.
Although Andy might have been mistaken in his review that the newer versions are using pure perl, I believe he has good reason. I just benchmarked 1.52 against 2.015, and 1.52 is a little more than twice as fast in both compression and decompression as 2.015.
Parse::CPAN::Packages::Fast is about an order of magnitude faster and uses only 40% as much memory. Neither, however, offer a way to iterate through the list without first creating the entire list in memory.
According to the docs this is just a fork of Geo::Coder::Google that offers no addional functionality or bugfixes. It simply interfaces with Google via JSON, instead of XML. It also behaves differently than all the other Geo::Coder modules- instead of returning a simple hashref, it returns an object.
This is just horrible namespace pollution. It should live under the Acme namespace, where the rest of the pointless modules go to die. Seeing poor choices like this make me less inclined to use any of the author's other modules.