I am an indirect long-term user of this module via other modules that needed it and therefore was one of the victims when it broke for non-threaded perls a few years ago, with all the hassle of investigating, hoping for a while, and eventually migrating away from the modules that needed it.
Coincidentally I just found this module again, and can happily confirm that it works again.
I used it to kill trees of processes using killfam and to explicitly collect such trees for other operations using Proc::ProcessTable, and Killfam::get_pids().
I could confirm its functionality with an independent pstree shell scripting solution I wrote as fall-back.
Although I only used it on Linux yet I skimmed the source to get some confidence how it approaches platform independence, and it looked good to me.
Thanks to JWB for getting this module back on track.
Inconceivable that I would ever write a review like this but the other ones have probably not really read what the SYNOPSIS says. This module is quite for sure *not* just a repetition of all the other "use strict, use warnings"-approaches, and it's also not the opposite. Just look twice. And for its chosen middle-way it's also not the worst name ever. And everything is documented.
In 2006 I did a real world project where I solved some parts in PROLOG. I thought about available Perl-only logic programming solutions on CPAN but after some experimenting recognized Language::Prolog::Yaswi as the best choice because sooner or later you need some real PROLOG-only features and you need to ask the according communities, which can better help you when referring to a real PROLOG they know.
The existence of this lib also was my primary decision criterion for SWI Prolog over GNU Prolog.
I used both directions, mostly PROLOG from Perl but also provided some functions from Perl to the PROLOG library (namely some DateTime functionality). It worked as documented, although as usual you should take some time for fiddling the best way how to organize both your Perl and (mostly) your PROLOG libs, e.g. when to use libs and namespaces, where to store PROLOG files, etc.
For testing I can recommend the "Autotest for SWI-Prolog" library which I simply adapted to print out TAP. This way you can test the PROLOG subsystem and the integration from within your Perl project.
The author was responsive for bugreports (something in SWI PROLOG had changed), investigated and fixed it. Everything felt matured (for those who don't trust version numbers below 1.00).
Thanks for this powerful lib that opens up a powerful different programming paradigm in The Right Way.
This module earns the most respect for being the base for some other new and hot CPAN modules like TryCatch, MooseX::Method::Signatures, MooseX::Declare, MooseX::MultiMethods, etc., which marry Perl6 like functionality with Perl6 like syntax and by that bring us a modern and aesthetic way of programming, all in Perl5.
This module is not necessarily meant for the "end user". Look at
No rating, I'm biased, only a hint for people who just discover this module because it is prominently named in books on the market:
If you are looking for how to do OO in Perl then please have a look at more modern approaches, in particular "Moose". That will provide you with a much more concise, more natural and very modern interface.
This module helps surviving in a multi-language work environment where you need to participate in the discussion about the typical Perl FUD. And, admittedly, it really adds even more beauty and readability to your code.
I used it in the context of a Moose'ified and RPC:XML::Server-based application, providing an IMHO sufficiently complex environment of subs and methods that finally gave me a good feeling about this module, not being that alpha grade as it calls itself.
I would, of course, really appreciate it if the trailing semicolon after a method can be avoided. But currently the advantages in readability are worth it.
I'm a long term user of this module, even before it's existence on CPAN. This module works good for me.
Why only 3 stars?
Generally it's good that this module is now on CPAN after it was hidden from most of the world on a japanese site. Unfortunately there are some issues with it:
- The file should use a lib path that matches its namespace, i.e., lib/DBIx/Class/Schema/Loader/DBI/Oracle.pm.
- It should be merged into the DBIx-Class-Schema-Loader package. In fact it already exists there but is hidden from pause indexer. (Strangely this only works because of it's original wrong lib path, see first point above.)
- It has documentation issues, eg. it uses "Postgres" in its description, probably because it was forked from that package. It's not that critical but such things make the user unsure. The hidden instance in DBIx-Class-Schema-Loader already fixed that.
My suggestion: Merge and fix the documentation (eg. the DBD::Oracle speed hint) into the DBIx-Class-Schema-Loader instance, no longer hide that other instance from indexer and take this instance here away again from CPAN.
I know, that it's a pity to give up on modules for the sake of authors reputation, but having it central in DBIx-Class-Schema-Loader is more worthy for the users. Maybe just incrementing version number in the DBIx-Class-Schema-Loader instance solves the reputation problem.
CPAN.pm was of so high quality for so many years that I simply want to say Thank You for this module.
Some time ago I very often heard that CPAN.pm had too difficult internals, everything would be quirky and unmaintainable, etc. This might be true, I don't know and I don't care, because CPAN.pm (or better say its author) *never* let me alone. It always worked very robust for me on different platforms and with practically every version of it I tried.
It especially worked much more reliable than its designated successsor CPANPLUS. I tried to switch to CPANPLUS some years ago but switched back to CPAN.pm simply because of the much higher reliability.
And since the once stalled development resumed with support for Module::Build, CPAN::Reporter, etc., my CPAN world is in perfect balance.
I'm coming from the explicit DBI/DBD/SQL programming world and are just switching/learning to the way of ORM. Therefore my point of view is rather at a beginner level.
DBIx class is really nice if you follow the path of the examples with widespread open source databases like MySQL. I mostly used it from within Catalyst and I got practically all simple and enhanced query problems solved quite elegant without programming in SQL.
So, why not 5 stars?
Because the documentation may become very confusing once you have to use another database system (Oracle in my case) and the basic examples are not enough or you need to do manually what normally Catalyst helper scripts do for you.
Then the documentation too often says "see This::Other::Related::Module". This might be true but requires you to understand each of those other related modules and to click through the hell of the circular dependencies between all those modules which is very annoying once you lost the thread. All this got worse when some of similar modules or some single methods just went deprecated. I really got lost there.
I wish the documentation would simply be more explicit even if that means doubling some prose and examples. Currently it feels a bit too much from a point of view of advanced regular DBIx::Class users.
Update 2008-05-30: I raise my rating to 5 stars. The docs got better and it's so worth all the effort to understand this ORM because it gets more and more fun the more you get used to it and the community on irc helps you with every problem within minutes. What else should they do to earn 5 stars?
It is extremely powerful, although by using Perl as its template language it desires some discipline to take care of separating logic and layout.
Self decided discipline is what a Perl programmer needs anyway in larger projects, so it's ok, but don't expect your non-Perl project fellows to love mason templates.
With Mason you can do with your layout code (the templates) what you do with your normal code all the time: restructure every snippet that occurs to be reusable. Masons well-thought component API allows you to do this in various ways: with OO like inheritance, function or macro like calls or just "classical" template including.
There is syntactic sugar everywhere, exactly when you just realise you could need a feature there. Example is the filtering of output with or without entity encoding.
For web programming I prefer Mason over Template-Toolkit (which in turn I prefer for strange text templating, so it's no criticism of TT).
The only thing that I don't like is its prerequisite to Apache::Request which in turn tries to install libapreq which in turn is, depending on the OS, a "challenge" (to avoid the word "problem") for itself and practically everytime better installed with the OS distribution tools or by the sysadmin. I don't know why this dependency is set because Mason can be used without Apache or mod_perl, e.g. with Catalyst. Maybe a historical legacy. I would like to see that coupling divided.
Another thing that might take some time is to customize you editor for mixing highlighting of Mason/HTML and Perl syntax. At least with Emacs it kept me awake some time to fiddle with MMM-mode.
I like the idea of this module and even tried to reuse its contained collection of regexes, servers and answer types. Unfortunately it's probably too old to really recognize and handle most of the currently typical answers from whois servers.
I took Net::Whois::Raw instead and did some heuristically regexing for myself.
I try and retry YAML once a year. I'm really willing to give it a
chance but I'm still unsuccessful.
YAML calls itself a data serialization language. And that's exactly
what I can't do without fear. For years now.
In the early days it misinterpreted hash keys and values in subtle,
hard to expose ways (leading zeros, version numbers and excessive
newline/carriage-return usage). Ok, with >= 0.37 the hard times of
ForceBlock seem to be gone, fine.
Now I fight with segmentation faults when my strings contain strange
characters (I can't reduce it to minimalistic data examples, sorry,
maybe I report my examples anyway, the longevity of unresolved bugs
on rt.cpan.org kept me away so far).
I don't want to think about the "right" content of my data when I use
something called "data serialization language". I like the good warm
feeling when using Perl for handling my data, and this feeling went
away every time I tried YAML.
In my understanding the root for the problems is the own data parsing
although using Perls parser (via eval) eventually would be more
robust. (Yes, I read about the advantages of not using Perl's eval.)
Don't get me wrong, I respect the idea, the YAML format itself and the
implementation, too. I just had problems with it since my first
try. More than with other CPAN modules.