This module is incredibly simple and makes installing long-named modules a breeze.
My one complaint is that there's no reason this should be limited to cpanm -- it would work for regular "cpan" too. I'd like it to be more configurable -- let me customize the commands that I want CPAN module completion for.
Parallel::Iterator is an excellent tool for parallelizing IO tasks or taking advantage of a multi-core CPU. The simple API hides all the process management and communication complexity. All I need to do is write an anonymous subroutine as the "worker" and Parallel::Iterator takes care of the rest.
RJBS is a fabulous programmer and human being. Not only the Perl community but the entire world would be better off if more people could be like RJBS. This excellent distribution provides a nicely categorized list of CPAN distributions that every serious Perl programmer should consider having in their toolboxes. Plus, as a Task module, it lets you install them all easily.
This module is short and simple and solves a (somewhat common) need in testing. From the time I found it on CPAN to when I used it to verify that my tests performed correctly was just a couple minutes. It's a very handy addition to the toolbox.
This module is so handy, it should almost be the default for Perl. Why should anyone want identical, repeated warning messages? This module suppresses the duplicates and prints the warnings only once with a count, instead. Very handy to have in your Perl tool box.
It has one very specific purpose and does it well. And thank goodness for this version which uses HTTP instead of FTP. Install this, set your .pause, and then release to CPAN without ever needing your browser.
This is the only output capturing module I've ever seen that *doesn't* use tied handles, but instead uses a more robust approach with temporary files. As a result, it can capture output from perl code, XS and external processes. The interface is clean and well documented. I wish I'd known about this a long time ago.
This module attempts to straddle the line between strong encapsulation and DWIM. Its major features appear to be integrated trace logging and dynamic definition of attributes.
Unfortunately, it demonstrates a poor understanding of the nature and limitations of the inside-out object technique -- it's more akin to Conway's original "flyweight" pattern than a true inside-out object. Some observations:
* it stringifies the object for accessing the underlying lexical storage, which will break for objects that overload stringification; (refaddr should be used instead)
* lexical storage is a single hash in the base class namespace instead of using lexical storage in the derived classes; thus all attributes have method overhead for access and even private attributes are declared and accessed through methods
* as a result of the above, there are no compile-time checks for typos in the names of attributes, which is one of the frequently cited reasons for using the inside-out style
* worse, because attribute declaration is done via AUTOLOAD, attribute typos won't even be caught at run-time, but instead completely new, misspelled attributes will spring into existence
* hashification returns a reference to the underlying data rather than a copy of the underlying data, thus providing an API for breaking the encapsulation provided by using the inside-out style in the first place
* not thread-safe (via CLONE method or other approaches) -- though the author notes it hasn't been tested for threads
* forces the use of a blessed scalar in new, preventing foreign inheritance, which is one of the other reasons frequently cited for using the inside-out style; doesn't use the scalar for anything useful to compensate for this loss (such as storing a globally unique ID that could be used instead of object memory address for thread-safety)
* not serialization compatible via any of the standard tools, like Storable; the only serialization provided is dumping via Data::Dumper and only to STDERR
In summary, while this module clearly works for the author, I strongly recommend that others avoid it until the author addresses many of the points above.
For inside-out objects, I recommend instead either Class::InsideOut (which I wrote) or Object::InsideOut. The first is simpler; the second more featureful.
This is a fantastic tool for quickly checking how backwards compatible your code is. It's great for catching all the syntaxt that drifts in by habit (e.g. "use warnings") that gets in the way of backwards compatibility.
This module is far and away the fastest, most-complete, most-robust inside-out object builder on CPAN. It gets all the tricky complexities of inside-out objects right. I recommend it highly. Also, the author has been very proactive with improvements and bug fixes. One of its only downsides is that it is so complete and feature-rich that there can bit a bit of a learning curve making it through the extensive documentation.
To pile on, this generally not work for "inside-out" objects in pure Perl, either -- like those created with Class::Std, Class::BuildMethods, etc. *If* Storable is used as the base for this module's action and *if* Object::InsideOut is used with Storable support enable, then it *may* work. (Ditto for Class::Std::Storable.)
Incredibly useful! Despite the incomplete documentation, the interface is intuitive enough to make basic usage possible. I found it very handy for testing perl scripts, as it transparently feeds/captures STDIN and STDOUT from scalars and just works on both Linux and Win32. Still, I wish the documentation were improved as it seems to offer much more than I've managed to puzzle out so far.
This is a very elegant solution to the problem of CSV file modifications, particularly if you want to work with your CSV line by line rather than parsing a whole file. If you need to read CSV, modify it, then spit it back out as CSV, this module will work nicely. Unfortunately, some of the magic behind the scenes is barely documented. The result of reading a CSV line through this tied handle is a tied array or hash reference that stringifies back to CSV when printed. That's implied in the docs, but not really spelled out and some usage examples would make it much easier. (E.g., to print out only certain fields, you really need to do a hash/array slice and store it back in the same tied object.) I spent longer digging through docs than actually writing code to use it. That said it's still good to have in the toolbox.