A naÃƒÂƒÃ‚Â¯ve approach to data management, and a fatally flawed implementation. It is hard to see anything that this module does right, and the manuals are full of incorrect and ignorant statements - see the annotated POD for a couple of corkers I've found. The shocking approach to IO makes this module perform more slowly than a heavyweight RDBMS, but provides none of the guarantees.
I do not for a moment believe that this module is doing its storage safely. Avoid like the plague.
For a summary of better approaches, I currently recommend reading the data storage chapter of _Advanced Programming Perl, 2nd edition_ by Simon Cozens (O'Reilly).
Seriously, that's ridiculous - that's far too much data to link to an instance. You cannot sensibly serialize something like that using 'Storable' etc - a shame, because one of the strengths of using Date::Manip has always been its extremely lightweight memory use - 'YYYYMMDDHH:MM:SS+ZZZZ' is a very efficient format.
Does it seriously need more than: [ $iso, $epoch, $offset_sec, $zone ] ?
There are those who believe that all language features should be introspectable by an consistent object-oriented interface, and then those who believe that piecemeal procedural interfaces are sufficient.
If you're not sold on the first idea, you might reach the conclusion of Pista. In which case continue to use the old interfaces of yesterday, and hope that people don't ever call your code legacy as soon as you write it.
As author of one of the previous metamodel modules on CPAN, T2 - it is nice to see a new metamodel come out that has made Rightâ„¢ architectural decisions at virtually every step.
Being the result of a long and extensive period of collaboration and dialogue with the core Perl 6 development team and veterans of various object systems, and being heavily researched in such longstanding prior art as the Smalltalk and CLOS Meta-Object-Protocols, the long question of "which accessors module to use" has finally been solved in a way that allows a new wave of advanced tools to be developed, as well as paving the way for a smooth migration to Perl 6 objects.
Naturally if you are unfamiliar with the higher level tricks then this might seem a bit pointless. However, modules like Template::Plugin::Heritable would be needlessly complicated and restricted to a 10-year old object model without the sophisticated abstractions provided by Moose and Class-MOP.
Though a little short on docs and examples, with a bit of patience and experimentation it is easy to get curses forms and dialogs working with this module. I would certainly recommend it to somebody looking to have nicer prompts in their terminal applications, but who doesn't want to spend a lot of time messing around with it. Its widespread availability across Linux distributions is a bonus, too.
Look at the source of, eg, Curses::UI::Dialog::Question, for the shortcomings in this module - it is not possible to just throw a few widgets together to make a dialog. This module does nothing to avoid the user from having to do fiddly layout and offset calculations in the code that makes new dialogs, and regrettably the "Question" dialog is not extensible to exchange the default TextEntry widget with another.
I found this module has an enticing looking interface but was upset when I found it next to useless trying to use it. Next I'm trying Newt.
I rate this neutrally because I am the original author of Class::Tangram, and current maintainer of Tangram.
On first inspection, this module does not appear to implement any of the features of Tangram. It implements many of the features of the Class::Tangram accessor generation package. The distinction and seperation between the two parts is one thing that Aaron appears to have missed, and a key to the great flexibility of Tangram to use whatever accessor package you like.
So Pint Is (definitely) Not (anything even resembling) Tangram.
This module provides for development coverage testing in a far superior manner to other approaches like Devel::Coverage. The way it works is by replacing the `runops' C function in the middle of Perl - and this extremely low-level approach is the only way to ensure that your coverage tests are complete and transparent (apart from a minor performance penalty).
Paul Johnson explained the topic well at YAPC::Europe 2003.
Watch out for a funky new report format with newer versions!
Allow me to go against the grain here, but the only thing that mod_perl has going for it is that it is widely known and a lot of material and modules have been written for it.
Architecturally, it's a poor choice for building dynamic web applications. The problem is that the same process(es) are serving simple files as well as generating dynamic pages. This means that while images, etc are being served to clients by apache processes, all of the memory consumed by the Perl interpreter is essentially wasted.
The answer involves:
* hacking your application to fork() at just the right moment (which helps but doesn't address the real problem)
* setting up a Squid `reverse proxy' (Squid, using a select() loop model, is a far more efficient web server than Apache)
* running another version of Apache that the first one forwards requests to - the two processes communicating via HTTP.
* Using Apache/mod_perl 2.0, and hope that the threading model is stable enough for you.
It is also not possible (without installing a seperate Apache instance for each user) to use the Unix process model to seperate scripts for different web sites to run with the permissions of different users, for instance. Using Apache's `suexec' feature is incompatible with mod_perl and effectively reduces you to CGI performance.
It is widely accepted that once you hit a certain traffic level, you need to seperate front end processing from building dynamic page requests, and HTTP was not really designed for this; it works most of the time, but the integration is far from seamless.
People mention that some of the biggest sites in the world (Slashdot seems to be a common example, for some reason) use mod_perl, but they do not mention the blood, sweat and tears that were involved. Actually, the biggest sites in the world use extremely small web server processes, and binary-optimized protocols to talk to the real applications - these include NSAPI (SunOne/Netscape iPlanet), ISAPI (IIS), etc.
There is a binary optimized, Open Market standard that was designed for just this - FastCGI. See the FCGI module on CPAN and www.fastcgi.com/. FastCGI typically adapts quickly into Web Applicaiton Development Frameworks, and can increase performance markedly whilst requiring a lot less memory. FastCGI works with Apache, and the performance is on a par with mod_perl (actually, typically the performance is less subject to fluctuations).
It is for these reasons that I hold my opinion that Apache/mod_perl will be one day seen in the same light as Sendmail - filled with the cruft of years of creeping featuritis.