No overall rating since I have no use for this module, nor would I use it if I did. It really, *really* should not be used in production because of how it patches UNIVERSAL. Granted, since this module is in the UNIVERSAL namespace, that is no surprise, but I feel that the warning can not be understated for those who want this functionality and do not yet understand the ramifications of its implementation.
IMO, what would be better is something a bit more sophisticated (and in a different namespace) which takes as import arguments a list of modules to patch, and patches *only* those namespaces *lexically*.
That should not be hard to do by using some combination of B::Hooks::EndOfScope and Import::Into.
If you *really* want to be magickal, perhaps there's some way to determine which modules are loaded in the current scope, and patch *those* automatically (lexically, of course :)
Still, neat concept. I'd like to see a safer implementation!
After seeing it go by in my RSS feed I tried this out yesterday and I love the idea. As Steven Haryanto mentioned in his review, there are already other modules that do what this one does, but I like that L is so short that I don't think twice about using it for one-liners. Something to note is that of the modules Steve mentioned, only Class::Autouse does the exact same thing (automatically load a module when a method or sub is called on its namespace). The others will install missing modules from the CPAN when code wants to load them, but not automatically load them without a use or require statement.
There are a few minor reasons it doesn't get 5 stars though.
The most important is that this uses a somewhat dangerous and brittle hack, and a cursory look at the code leads me to think it could cause some unexpected behavior in some cases. (I'll file bugs if I stumble on any :). That said, the documentation clearly states that this is only intended for one-liners, and in that case, I've no problem with adding an AUTOLOAD to UNIVERSAL in exchange for such convenience.
Of less importance is that I'm not too keen on dists that take up a 1-character top-level namespace, even for something so useful. Two or three would be better, and still less typing than the alternatives.
Finally, I'd love it this eventually included some mechanism to try to download & install missing modules into a local::lib or something like that, perhaps reading an rc file in the user's home directory. Something like -ML=i, or -MLi=~/p5tmp (make/use p5tmp as a local::lib) Maybe just depend on lib::xi and be done with it.
My thinking? Since it's already doing a little black magick, it might as well go full-on warlock.
[edit: added some more info on alternatives]
Overall, a very good module. It was just what I needed to provide a java-style config (properties) file for an application living in a Java environment. Only thing I would want is for the ::Simple module to export a single function to read a properties file and output its contents as a hash in one simple step. Sure, that's easy enough to do oneself, but I'm lazy :)
After writing the nth CLI script this month I finally snapped and went searching for a Getopt:: dist that would allow me to get rid of a ton of boilerplate, as well as make my usual frankenstein's monster mashup of Getopt::Long + Config::General + Pod::Usage + some other random things a lot nicer and automatic.
Getopt::Lucid has handily replaced Getopt::Long in this stack, and the code is now far shorter, its usage is much more readable, and the little magic things I like my scripts to do like auto-generation of docs and help-text has become so much better.
Props to DAGOLDEN for another excellent addition to my toolbox!
Just the thing I wanted! 90% of the time I work with CSV I just want to slurp it into a hash or array, or spew the data out to a file. This lets me do it with a single method call!
Sure this isn't for everybody, but it works lexically and that makes it A-OK in my book. Recently I have been looking at putting together an in-house "Modern::Perl" or "common::sense" module for enforcing our code-standards and this seems like a worthy addition.
If you're not using local::lib, you *should*
The vast majority of module installation and dependency problems I have encountered and helped others with are a direct result of running cpan as root and installing to the system perl's libraries.
local::lib allows you to install cpan modules to a "private" directory that you control, and does not affect the system and other users. You can have several of these local libraries and switch between them. You can check them into version control. You can experiment with upgrades, modifications, fix bugs, et al. to your heart's content.
I won't claim that it will work for every module out there but it must be damn close - I've *never* encountered a module that will install to the system libs but not install to a local::lib. If you find one, file bugs on both local::lib and the broken module. (it's almost certainly the module that's broken)
One more thing: I've written a handy little bash script that will automatically bootstrap local::lib and cpanminus for you... github.com/Hercynium/boostrap-user-perl It's rough but it works for me. Bug reports and patches welcome!
Previous comment was not a review. It is an abuse of CPAN Ratings.
And to be serious, Perl::Staff is simply yet another dist that does this sort of thing (ie. nothing but list names). It's a tradition. See Acme::CPANAuthors for another example.
Hands down, far and away the best performance profiler I have ever used, for *any* language!
Version 4.04 even traces code within string eval, which to me is nothing short of amazing. Using it with Perl 5.10.1+ adds even more capabilities, due to new magick within the perl VM.
The HTML output is even highly useful as a general code browser!
@Nigel - your assessment is 100% incorrect. NYTProf, by default, profiles *all* the Perl 5 code that your application uses. If you are having difficulty, ask someone for assistance.
Not a review since I haven't used this particular module (I've used its big sister) but more a suggestion to other reviewers: If you find a bug or have a complaint, file a bug report! The link to the module's RT queue is right in the documentation page, on the right! This is not an old module, and I don't see any evidence that the author is missing or unresponsive.
Also, the docs clearly state, "NOTE: The code does not currently check for cycles, so infinite loops are possible"
Sure, I would want this to be in big bold at the top of the docs... but it's certainly not buried. If you want that feature so badly, file a bug report and/or send patches! Heck, file a report asking for the docs to be more clear about this limitation until it it resolved!
Most CPAN authors love learning that others are using their code and *want* to improve it. Give them the chance to do that and you might end up impressed!
I use this module to generate my invoices since I track my hours in Google Calendar. The script was easy to get working and has never let me down once!
If you need to find stuff on the backpan in bulk, BackPAN::Index is pure awesome-sauce. Considering the fact that the BackPAN isn't indexed nearly as comprehensively as I would like, as long as you understand what little info is actually available, this module makes working with it bone-easy.
I only gave docs a 4 because I did find myself digging through the source to figure a few things out but that may be because I needed to know exactly what was happening behind the scenes for my project and perhaps not everyone will need that.
As far as Apache configuration modules go, this one's the best on CPAN. The only other thing I could ask for would be a mechanism to follow Include directives and dynamically add directives in new files and then write them out properly. However, having everything in one httpd.conf isn't so bad when you have a perl module that works this well!
My only gripe so far is the lack of a method for RR objects that would allow extracting of hostnames from a query answer using a single function call. Of course, that functionality is trivial to implement, so it's not a big problem.
Otherwise, the Net::DNS module is highly functional and useable!