Badly documented and totally over-complicated and bloated specification.
The point of POD was always simplicity of documenting your Perl modules and
applications. 'perldoc perlpod' could be read withing a very reasonable amount
of time and could be understood without an diploma.
perlcabal.org/syn/S26.html shows excellently how ambitious goals can
lead to a bloated set of features. It's a very good example of the Second
System Effect (see also www.c2.com/cgi/wiki?SecondSystemEffect).
One of Perl6's goals was: "The Perl 6 design process is about keeping what
works in Perl 5, fixing what doesn't, and adding what's missing.". In case of
Perl6's Pod specification it looks more like "..., adding every feature that
could be remotely useful.".
The specification is not Perl6::Pod's fault, but there still exist one actual
problem with the module: Ironically the documentation seems to be completely
absent (except some short examples in the synopsises).
I appreciate very much the time that ZAG invests and it's very good
that some people out there in the Perl6 land actually/finally code something.
1 out of 4 found this review helpful. Was this review helpful to you? Yes No
I use common::sense in all my applications now. Next of my
module releases will use it too. It saves me a lot of typing 'use strict; no warnings;' becomes 'use common::sense;'.
4 out of 12 found this review helpful. Was this review helpful to you? Yes No
Finally a AnyEvent based SMTP Client AND Server!
The code looks promising and slim. If you need an easy to use
and non-blocking event based SMTP Server and/or Client you
should try this module!
2 out of 2 found this review helpful. Was this review helpful to you? Yes No
Provides a nice interface to report new mails in your gmail mailbox.
If you need a more generic alternative (you still need to provide the
right url and all) try looking at AnyEvent::Feed.
2 out of 3 found this review helpful. Was this review helpful to you? Yes No
Just wanted to say: It works really nice! And it seems to make
easy to tackle the problem of all those different feed formats.
I've just yesterday released AnyEvent::Feed, which is a nice
convenience wrapper around AnyEvent::HTTP and XML::Feed. It works
really well for me :) Without XML::Feed I would've stayed out of
the Web 2.0 feed world :-)
3 out of 5 found this review helpful. Was this review helpful to you? Yes No
I'm using AnyEvent for around 2 years now. My modules Net::IRC3,
Net::XMPP2, AnyEvent::HTTPD (will soon be released) and Text::Edit
use it for their I/O events. It has been very stable for quite some
time now, and all bugs I occasionally found and reported have been fixed very quickly.
I also like that it doesn't enforce a framework upon me, like POE or
IO::Async would do. You just create some watchers for the events you
like, specify the callbacks and you are ready to go.
The documentation is a good reference and also comes with useful
examples. It's also very good that all quirks in the interface
are nicely documented. For example the exact behavior of C<wait>
I give 5 overall stars as it proved to be stable, is very easy
to use and I consider it a very good policy free alternative to
all other event frameworks.
10 out of 13 found this review helpful. Was this review helpful to you? Yes No