Acme-CPANModules-Import-CPANRatings-User-stevenharyanto

 view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    Opt::Imistic
        Author: ALTREUS <https://metacpan.org/author/ALTREUS>

        Very nifty for short scripts and some clever design inside (all
        options are stored as arrayref, but there is some overloading to
        make getting boolean/flag and normal scalar value convenient).
        <br><br>For more &quot;proper&quot; scripts though (anything above
        say 20-30 lines) I'd recommend using something like Getopt::Long
        with a real spec. Some of the features I like in G::L not in
        Opt::Imistic: the ability to get --noOPT for free for flag options,
        the ability to configure permute/no_permute (mix mashing options
        with arguments), some data validation, and of course:
        autoabbreviation of long option names, which requires a spec after
        all.

    Devel::STrace
        Author: DARNOLD <https://metacpan.org/author/DARNOLD>

        The doc looks promising, it really looks like it could be the
        &quot;strace for Perl functions&quot;, but the usage is awkward (you
        have to open two terminals, one for running your program and
        producing trace file, and another for reading this file). And I'm
        probably an idiot, but I can't get this module to work for me.
        <br><br>One alternative if you're looking for a similar module is
        Debug::LTrace. <br><br>

    Devel::TraceSubs
        Author: PARTICLE <https://metacpan.org/author/PARTICLE>

        For an alternative, try Debug::LTrace, which roughly provides the
        same basic feature but is more convenient to use from the
        command-line and give extra information like timing. <br><br>

    Devel::TraceCalls
        Author: COSIMO <https://metacpan.org/author/COSIMO>

        Might be powerful and flexible, but not convenient to use especially
        from command-line. (I was searching for something like &quot;strace
        for Perl function&quot;). <br>

    Debug::LTrace
        Author: KOORCHIK <https://metacpan.org/author/KOORCHIK>

        One of the more convenient and usable subroutine tracing modules on
        CPAN. If you're looking for something like &quot;strace for Perl
        functions&quot;, try this. <br>

    Debug::Trace
        Author: JV <https://metacpan.org/author/JV>

        Good module, but try its derivative Debug::LTrace instead.
        Debug::Trace doesn't fake caller() yet so traced/wrapped subroutines
        get caller() results that are &quot;off-by-1&quot; (see
        Hook::LexWrap). Plus, Debug::LTrace gives more information like
        timing. <br><br>

    App::Trace
        Author: SPADKINS <https://metacpan.org/author/SPADKINS>

        The name and abstract is slightly inaccurate/misleading. This module
        is supposed to be a general logging framework instead of just
        subroutine entry/exit tracer. For alternative subroutine tracer, I'd
        recommend Devel::TraceSubs or Devel::TraceCalls (or even
        Devel::Trace + variants). <br><br>Not very convenient to use. It
        still requires you to put 'if $App::Trace' clause everytime. For
        general logging that can be switched on/off upon runtime, I'd
        recommend using Log::Any instead. <br><br>Lastly, this module is
        tied to App::Options and thus only really usable if you use both.

    Tie::Hash::Identity
        Author: CINDY <https://metacpan.org/author/CINDY>

        Hash::Identity has a use case of convenience when embedding
        expression in double-quote strings. I fail to see the point of
        Tie::Hash::Identity though. Can't you just say: <br><br>'abc' eq
        'abc'; # true <br><br>(1+2+3) eq '6'; # true <br>

    Hash::Identity
        Author: CINDY <https://metacpan.org/author/CINDY>

        At first I thought, hey, cute trick. But then Perl already has:
        <br><br>print &quot;You could use expr like this:
        ${(2**3)}.\n&quot;; <br><br>print &quot;Or you could use ident ${(
        'a' . 'b' )} as well.\n&quot;; <br><br>So you're trading a backslash
        and a couple of parentheses against having to depend on a non-core
        module and making your code reader raise her eyebrow when she first
        sees your code. Pick your poison :-) <br><br>I wonder if this
        belongs in Acme:: <br><br>On the other hand and slightly off-topic,
        a module that can do Perl6-style interpolation (lexically) would be
        cool, I think: <br><br>$s = &quot;perl${(6-1)}-style
        interpolation&quot;; <br> { <br><br>use v6str; <br><br>$s =
        &quot;perl{ 5+1 }-style interpolation&quot;; <br> } <br>

    Data::Structure::Util
        Author: ANDYA <https://metacpan.org/author/ANDYA>

        @Tom Browder: If you just need unblessing, there's also another
        module Acme::Damn which is more minimalist. You can also create a
        shallow copy to unbless a reference, if you want to do it without
        the help of any module (Both Acme::Damn and Data::Structure::Util
        are XS modules, JFYI). <br><br>Re Data::Structure::Util: nifty
        module that provides speedy alternative for several things like
        checking for circular references, weaken them, unblessing a
        reference, etc. You can do many of the routines in pure Perl. This
        module lets you do them in C. <br>

    Fsdb
        Author: JOHNH <https://metacpan.org/author/JOHNH>

        An interesting tool that has been developed since 1991 (which is
        roughly around the time the WWW and Linux was born, whew). Kudos to
        the author for the dedication and consistency. <br><br>Since
        nowadays SQL is pretty much ubiquitous, users might also want to
        check out an alternative tool, App::fsql. For example (taking a
        similar example from the module's doc), to select entries in
        /etc/passwd where UID is between 1000 and 2000: <br><br>$ ( echo -e
        &quot;login\tpassword\tuid\tgid\tgecos\thome\tshell&quot;; sed
        's/:/\t/g' /etc/passwd ) | fsql --add-tsv - 'SELECT * FROM stdin
        WHERE uid &gt;= 1000 AND uid &lt;= 2000' --format text --aoh

    Date::Tie

README  view on Meta::CPAN

        edits. I appreciate the effort of the author to defend her module,
        though I am not convinced by her arguments.

    Dist::Zilla::Shell
        Author: DOLMEN <https://metacpan.org/author/DOLMEN>

        Nice tool that lets you type dzil commands like 'build', 'test', etc
        while sending all the other unknown commands like 'ls -l', 'man Foo'
        to the underlying shell. Also lets you avoid multiple startup
        overhead of dzil :-)

    CPANPLUS::Shell::Curses
        Author: MARCUS <https://metacpan.org/author/MARCUS>

        Unmaintained. Installs but no longer runs.

        Rating: 2/10

    Task::Mechanistic
        If you peek into its Makefile.PL, you'll see a seemingly
        random/heterogenous collection of modules to install (instead of
        just WWW::Mechanize). This is probably a Task::BeLike::$AUTHOR in
        disguise. <br><br>

    Sereal
        Author: YVES <https://metacpan.org/author/YVES>

        So far the best of the bunch. <br><br>FAST: much faster than
        Storable, roughly the same speed as (sometimes slightly faster than)
        Data::Clone for cloning. <br><br>FEATUREFUL: Can handle circular
        references, Regexp objects (trips out-of-the-box Storable),
        JSON::{PP,XS}::Boolean objects (trips Data::Clone). <br><br>COMPACT:
        definitely more compact (up to several times) than Storable.
        <br><br>I'm sold. What more do you want? Le Storable est mort, vive
        le Sereal!

    Test::Tester
        Author: EXODIST <https://metacpan.org/author/EXODIST>

        If you write test functions, you need this. It's like the
        &quot;Test::More&quot; for &quot;Test::More&quot;. However, it
        currently does not work out of the box with subtests (submitted as
        wishlist to RT). <br><br>PS: Thanks to Toby Inkster for pointing
        this module out. <br><br>

    Text::CharWidth
        Author: KUBOTA <https://metacpan.org/author/KUBOTA>

        It's faster than Unicode::GCString-&gt;new($str)-&gt;columns, but it
        gives wrong answers to lots of characters, e.g. control characters
        like &quot;\n&quot;, &quot;\t&quot;, etc are currently assumed to
        have width of -1 character. You're better off with
        Unicode::GCString.

        Rating: 2/10

    App::Options
        Author: SPADKINS <https://metacpan.org/author/SPADKINS>

        2010-10-13: <br><br>I admit, this is not the most flexible
        configuration framework out there as it enforces some convention.
        And I don't/can't use it on every project. But it's certainly one of
        the easiest. You can slap a few lines of options declaration in your
        code and voila, your script suddenly can accept command line
        arguments, has --help message et al, read from config files (in
        several preset locations). <br><br>There are still a few annoyances
        (I submitted them in the RT), but in general, this is a very handy
        module to use for lazy coders who just want to accept
        configuration/options from outside the code. <br><br>&lt;shameless
        plug&gt;I'm trying to do somewhat the same with Config::Tree, but as
        of now the module is not really done yet.&lt;/shameless plug&gt;
        <br><br>UPDATE 2013-08-15: <br><br>I'm reducing the ratings from 5
        to 2. I've now avoided using this module due to two lingering issue
        since 2010: 1) App::Options does not accept '--opt val', only
        '--opt=val' which is incompatible with how most command-line
        programs work, causing confusion for some of my users. 2) 'perl -c'
        doesn't work under this module, it will still trigger command-line
        processing. <br><br>I'm now using Perinci::CmdLine as replacement,
        but I cannot recommend it in general, as the two modules are not
        equivalent.

        Rating: 4/10

    Filesys::Notify::Simple
        Author: MIYAGAWA <https://metacpan.org/author/MIYAGAWA>

        It's rather unfortunate that currently the choice for general
        purpose cross-platform filesystem notification modules on CPAN falls
        between this module (FNS) or File::ChangeNotify (F::CN). The other
        CPAN modules are either OS-/framework-specific. <br><br>FNS has a
        simple API but is perhaps too simple for some uses, while F::CN uses
        Moose and has a big startup overhead. <br><br>If you simply want to
        check from time to time whether a change has occured, you need to
        wrap the wait() method with alarm(). And I found on my Linux PC that
        I need a timeout of at least 3 seconds for this to work reliably.

        Rating: 8/10

    experimental
        Author: LEONT <https://metacpan.org/author/LEONT>

        Vote +1 to add this to core. Please make coding in Perl 5 relatively
        painless.

    MIME::Lite::HTML
        Author: ALIAN <https://metacpan.org/author/ALIAN>

        Very straightforward to use (I needed to send a URL/webpage as HTML
        email with embedded images/objects). With this module I can finish
        my job with only a few lines of Perl in 3-5 minutes (searching for
        this module in CPAN takes more than that! searching using &quot;mail
        web&quot; or &quot;email url&quot; at first didn't get results).
        <br><br>Blackberry is having trouble displaying the resulting email
        though. No problem with Gmail or Thunderbird/Icedove.

    Term::Size
        Author: FERREIRA <https://metacpan.org/author/FERREIRA>

        5-year old bug like RT#38594 still present. Use one of the alternate
        implementations like Term::Size::{Unix,Win32,ReadKey}. <br>

        Rating: 2/10

    DateTime::Format::Flexible
        Author: THINC <https://metacpan.org/author/THINC>

        While it doesn't cover as much phrases as DateTime::Format::Natural,
        at least it's simpler to translate (and the dist already includes a
        couple of translations). BTW, I think like in the POD of
        DateTime::Format::Natural, it needs to list which phrases it
        supports. And probably add more :-) <br><br>

        Rating: 8/10

    DateTime::Format::Natural
        Author: SCHUBIGER <https://metacpan.org/author/SCHUBIGER>

        I'm giving DateTime::Format::Natural 3 stars because while it's
        great for English (it covers more phrases than
        DateTime::Format::Flexible), it's also hard to translate. Look at
        the source code for DateTime::Format::Natural::Lang::EN: lots of
        Englishisms and weird structures (%grammars). Wonder why so far
        there has not been any translations to another language? <br>

        Rating: 6/10

    App::sourcepan
        Author: PEVANS <https://metacpan.org/author/PEVANS>

        Thanks, just what I needed. (I was hoping cpanm would accept my

README  view on Meta::CPAN

        not enough or how it is different from Probe::Perl. <br><br>Anyway,
        quoting CPAN Testers' CPAN Authors FAQ, $^X is not enough when: <br>
        1) perl was executed with a relative path and the script has
        chdir()ed; 2) because $^X originates in C's argv[0] (in the main()
        function) it is possible for the calling program to exec() in such a
        way that argv[0] isn't the path to the interpreter; 3) HP/UX can do
        weird stuff in scripts that use #!; 4) VMS. (Not clear about #4
        though :) ).

    Taint::Util
        Author: AVAR <https://metacpan.org/author/AVAR>

        IMO this is the best module to deal with tainting. BTW there are
        several other modules like Taint (only provides taint + tainted, no
        untaint), Untaint (only provides untaint with awkward interface,
        like $v = untaint(qr/.../, $v)), Scalar::Util (only provides
        tainted), Test::Taint (does not provide untaint but provides
        taint_deeply and test predicates), and several others.

    Markdown::Pod
        Author: KEEDI <https://metacpan.org/author/KEEDI>

        I use Markdown::Pod for my module Perinci::To::POD. <br><br>This
        module does not output proper POD for many (not so) edge cases,
        like: <br><br>"&gt;" and the likes are not yet escaped, producing
        C&lt;&gt;&gt; when it should have been C&lt;&lt; &gt; &gt;&gt; or
        C&lt;E&lt;gt&gt;&gt;. <br><br>Ordered list numbering does not yet
        work, e.g. &quot;2. ...\n3. ...\n&quot; produces &quot;=item 1. ...
        =item 1. ...&quot; <br><br>Ordered list with item numbered other
        than 1 does not work (see above). This should be supported in POD
        because POD allows us to write the bullets/numbers for each item.
        <br><br>Inline markup is not smart enough to differentiate
        word_with_underscore. So &quot;foo_bar and foo_baz&quot; becomes
        &quot;fooI&lt;bar and foo&gt;baz&quot;. <br><br>Plus it segfaults
        sometimes (might be my perl though).

        Rating: 4/10

    Lingua::Metadata
        Author: MAJLIS <https://metacpan.org/author/MAJLIS>

        As previous reviewer noted, this module is actually just a front-end
        to the author's web service. Plus license is specifically BSD (which
        allows this module to be included in closed source projects), this
        is rather ironic to me. <br>

    Finance::Currency::Convert::WebserviceX
        Author: CLACO <https://metacpan.org/author/CLACO>

        Simple, no-fuss interface, recommended. As mentioned in the doc, the
        alternatives have some downsides: Finance::Currency::Convert::Yahoo
        is based on web scraping while ::XE has usage limits. <br>

    Carp::Always::Color
        Author: DOY <https://metacpan.org/author/DOY>

        Like Carp::Always? Want something better? Here it is. <br>

    CHI Author: ASB <https://metacpan.org/author/ASB>

        The DBI of caching. Stop reinventing your caching framework and just
        use this. <br><br>UPDATE 2013-01-16: unfortunately, the use of Moose
        reduces the usefulness of CHI for command-line scripts (0.2s/146
        files/53k lines startup overhead just to initialize a File cache).
        So 4 stars instead of 5. Let's hope the author migrates to Moo
        someday. <br>

        Rating: 8/10

    Monkey::Patch
        Author: FRODWITH <https://metacpan.org/author/FRODWITH>

        Compared to several other monkey-patching modules (like Sub::Monkey
        or Class::Monkey) I prefer this one because the interface is
        simplest and the documentation is the most straightforward. Plus it
        can do stacked patching and unordered restore, which is cool.
        <br><br>

    Log::AutoDump
        Author: CAGAO <https://metacpan.org/author/CAGAO>

        This module is simple and to the point. Unfortunately, if you're a
        user of Log4perl or other logging framework, you'll have to switch
        just for a single feature (autodumping). <br><br>An alternative is
        to use Log::Any, which also features autodumping (via
        $log-&gt;debugf(&quot;%s&quot;, $complex), $log-&gt;warnf(), and
        friends), while still allowing you to use Log4perl and other
        frameworks supported by Log::Any. <br><br>

    List::Pairwise
        Author: TDRUGEON <https://metacpan.org/author/TDRUGEON>

        Two nice and possibly very useful functions. But IMO the names
        'mapp' and 'grepp' are two similar to 'map' and 'grep', making it
        prone to typos and misreading. Perhaps consider 'map2' and 'grep2'?

    Log::Log4perl::Appender::File::FixedSize
        Author: HOREA <https://metacpan.org/author/HOREA>

        Module name should perhaps be
        Log::Log4perl::Appender::File::RoundRobin to make it clearer that
        the backend is File::RoundRobin. <br>

    Any::Mo
        Why exclude Moo? <br><br>Also the issue with any Any::* (or Any::*)
        modules is that there should be a mechanism (preferably a common
        one) to adjust the ordering. Sometimes I prefer Moose first, for
        full capability or compatibility or whatever. Sometimes I prefer
        Mouse or Moo, for quick startup (but don't mind Moose if those are
        not available). This also happens to me for YAML::Any: in some cases
        I prefer YAML::Syck, in others YAML::XS, this depends on the data
        that I'm handling. <br>

    PerlX::Perform
        Author: TOBYINK <https://metacpan.org/author/TOBYINK>

        I personally don't see much value of this syntactic sugar since Perl
        already allows us to express clearly. Pick one: <br><br>for ($foo) {
        say $_ if defined } <br><br>for (grep {defined} $foo) { say $_ }
        <br><br>do { say $_ if defined } for $foo <br><br>say $_ for grep
        {defined} $foo <br><br>And save yourself from having to remember
        whether we should add a comma or not before &quot;wherever&quot;.
        <br>

    TOBYINK::PerlX::A
        I have nothing against bundles like this, but beware that adding
        'use TOBYINK::PerlX::A' will cause Perl to load 460 files and
        compile +- 160k lines (takes 1s on my Core i5 machine and 8s on my
        Atom netbook).

    WWW::Google::Images
        Just adding a note that this module is unmaintained (as expressed by
        the author) and has stopped working for some time. If you are
        looking for alternatives, try REST::Google (which includes
        REST::Google::Search::Images). The latter has been working OK for
        me.

    Acme::Damn
        Author: IBB <https://metacpan.org/author/IBB>

        5 stars for cute metaphor (there's also Acme::Holy by the same
        author, but that is just another implementation of Scalar::Util's
        blessed()) and for prompt support from the author. <br><br>I'm sure
        there exists a real use case to move this out of Acme::, however
        obscure that might be. Can't come up with any right now, all I can
        think of is reblessing, which can be handled with bless() from the
        start. <br><br>UPDATE 2013-09-11: I found a real use-case for it!
        Cleaning up data to be sent to JSON. BTW, Data::Structure::Util also

README  view on Meta::CPAN

        so for sections of code that you're not sure about, just sprinkle
        'no autodie' to get the old behaviour. <br><br>It should be used on
        probably 95% of code out there. For the rest of the cases, where you
        need to report the status of each I/O operation, it's obviously more
        convenient to check $? instead of trapping exception everytime.
        <br><br>+1 for getting it into core. <br>

    App::FileTools::BulkRename
        Disclaimer: I maintain a &quot;competitor&quot; module, App::perlmv.
        Apparently a lot of people, like me, likes to rename files using
        Perl. And the examples in the documentation are about renaming movie
        files too, something which I do a lot :) <br><br>I applaud Stirling
        Westrup for taking a legacy script and improving it. May we have a
        lot of ideas to borrow from each other. <br><br>This is an early
        release, there are quite a few things I find lacking. Most
        importantly, I suggest adding a test suite as soon as possible. The
        filesystem differences can be tricky, and CPAN Testers can help
        providing feedback. <br><br>Keep up the good work.

        Rating: 8/10

    Script::State
        Author: MOTEMEN <https://metacpan.org/author/MOTEMEN>

        Nice idea, straight and simple interface. A better name could
        perhaps be chosen? Documentation should be expanded, e.g. to warn
        users about security, since Data::Dumper a.k.a. eval() is used to
        load variable content. Also, the implementation does not yet
        consider file locking.

    PathTools
        I guess File::Spec's API is sane enough, but I suspect not a lot of
        people are using it because there's not enough incentive for it.
        When 99% population of the world use Unix/Linux/Windows (even Macs
        been technically Unix for a number of years), &quot;/&quot; works
        everywhere and using File::Spec does not gain you anything except
        lots of typing exercise. <br><br>That's why I think Path::Class
        might have a better chance of succeeding. It gives niceties like a
        few more convenience methods, a shortcut of getting dir &amp; file
        object from each other, etc. It gives users more incentive of using
        a proper path manipulation library because it gives extra stuff
        along with that. It should also be in core to accompany File::Spec.

        Rating: 8/10

    File::Slurp
        Author: CAPOEIRAB <https://metacpan.org/author/CAPOEIRAB>

        I've been using File::Slurp for years and is generally satisfied
        with it. However reading the negative reviews today and looking at
        its RT queue, I realize that this module is broken for many and is
        effectively abandoned by the maintainer (no new releases for almost
        3 years now despite several RT items labeled as critical). So I
        suggest others checking out the alternatives.

        Rating: 2/10

    Log::Log4perl
        Author: ETJ <https://metacpan.org/author/ETJ>

        It's a very mature and an excellent logging framework. However, some
        of the common minor complaints are: 1) It's too complex. I agree: it
        should not be this hard to get started. 2) Configuration is too
        verbose. Agreed: but well, what can you do, most things from Java is
        a bit overengineered and verbose anyway. At least you can do almost
        anything with the configuration. 3) It's not very Perlish. Also
        agreed. 4) Performance. My note: speed is not an issue in majority
        of the cases and Log4perl's performance is adequate for most of the
        rest of the cases. For faster/leaner alternatives you might want to
        take a look at Log::Fast, but a lot of Log4perl's features are
        missing. <br><br>One of the main strengths of Log4perl is its
        sublogger/subcategory feature, which few other frameworks seem to
        have. <br><br>For other alternatives, also take a look at:
        Log::Handler, Log::Any. And of course Log::Message too. <br>

    Log::Handler
        Author: BLOONIX <https://metacpan.org/author/BLOONIX>

        This review mostly compares Log::Handler with Log4perl, which is a
        mature and one of the most popular logging frameworks. <br><br>I
        think Log::Handler's interface is much simpler, nicer, more Perlish
        than Log4perl. It's a bit similar to Log::Any::App, which I created
        just because I hate Log4perl configuration. <br><br>There is a
        unique concept of maxlevel not normally found in other frameworks,
        though it can be emulated in other frameworks using filters.
        <br><br>At a quick glance, the speed is around twice that of
        Log::Log4perl, so I'll say it's on the low-end side (there are other
        much faster logging modules, but anyway speed is not an issue to
        most people). <br><br>It currently lacks sublogger (hierarchical
        categorization and adjustable/automatic appending of subcategory to
        its parent), so it cannot be used to replace Log4perl in most cases
        as that's one of the main feature of Log4perl. Which is a pity
        because I would otherwise switch.

        Rating: 8/10

    Log::Fast
        Author: POWERMAN <https://metacpan.org/author/POWERMAN>

        This logging framework is also minimalistic: no
        categories/hierarchiecal loggers, no custom levels, no config file,
        or other whistles and bells. And the interface &amp; default levels
        are rather syslog-oriented. But it's fast alright. The POD doesn't
        mention a comparison to Log::Log4perl, but a casual benchmark shows
        that it's at least 10x faster. <br><br>So this module will certainly
        come handy if you have a performance critical application.
        <br><br>Btw, note that the benchmarks are done for actual logging to
        output. For log statements that do not actually get logged (e.g.
        because the level is below the desired output level), I don't find
        that extreme differences in overhead between logging frameworks. For
        example, on my Athlon64 X2 5600+ PC, Log::Fast's overhead is roughly
        around 3mils/sec, while Log::Log4perl is around 1,5mils/sec.

    Log::Minimal
        Author: KAZEBURO <https://metacpan.org/author/KAZEBURO>

        Log::Minimal's slogan is &quot;minimal but customizable&quot;. It's
        minimal alright, probably only suitable for simple scripts as the
        moment you organize your application/library into separate modules,
        you'll want/need categories instead of just level, which is not
        provided by Log::Minimal. <br><br>Also, only formats is
        customizable, there is currently no way to customize level. And the
        levels are &quot;not standard&quot; (not that there is an official
        authoritative standard, but the popular convention is
        TRACE/DEBUG/INFO/WARN/ERROR/FATAL and NONE). Log::Minimal's levels
        are <br> DEBUG/INFO/WARN/CRITICAL and NONE). Surely most people
        would expect another level between WARN and CRITICAL, for
        non-critical errors? But that is actually just a matter of taste.
        <br>

        Rating: 4/10

    Log::Fine
        Author: CFUHRMAN <https://metacpan.org/author/CFUHRMAN>

        Log::Fine is touted as a framework for those who &quot;need a
        fine-grained logging mechanism in their program(s)&quot;. But apart
        from the emphasis on custom levels, to me there is nothing extra
        fine-grained about it. The other thing it provides is
        categories/namespace, which is also supported by a lot of other
        frameworks. So I fail to see the benefit/uniqueness of Log::Fine.
        <br><br>Btw regarding custom levels, this practice is long
        deprecated by log4j (and thus also by Log4perl, although Log4perl
        can do custom levels). I can understand this decision as I sometimes
        already have trouble managing the popular convention of 6 levels
        (FATAL/ERROR/WARN/INFO/DEBUG/TRACE) as it is, much less with custom
        levels!

        Rating: 6/10

    Config::IniFiles
        Author: SHLOMIF <https://metacpan.org/author/SHLOMIF>

        This module has been developed for more than a decade and seen
        different maintainers over the years. The codebase is indeed showing
        these, with different capitalization and indentation styles, among
        other things. <br><br>However, among more than a dozen or so of INI
        modules in CPAN, ironically there seems to be few other choices if
        you go beyond the most basic feature set. Some INI modules can only
        simplistically rewrite/dump the whole INI structure and thus lose
        comments/orders, while others can't even write INI files.
        <br><br>Config::IniFiles by far offers the most options and
        features, like dealing with line continuation, case sensitivity,
        default section, multiline/array, deltas, etc. So for now, despite
        all of its quirks, this module is still hard to beat.
        <br><br>There's another nice little INI module that can do
        read/set/delete/unset (instead of just read/dump): Prima::IniFile,
        but it is included in a totally unrelated distribution.

        Rating: 8/10

    DateTime
        Author: DROLSKY <https://metacpan.org/author/DROLSKY>

        Amidst all the glowing reviews may I add a reminder that, as with
        everything, there's a catch: runtime performance. On my PC, the
        speed of creating a DateTime object is just around 6000/sec. If you
        use DateTime intensively, it can quickly add up. <br><br>Imagine
        serving a web page that fetches 50 rows from database, where for
        convenience you convert each date column to a DateTime object, and
        you have 120 requests/sec coming in... That's already 6000 objects
        (an extra second!). <br><br>Which is unfortunate because DateTime is
        so wonderful, convenient, correct, complete and all that. So one
        approach you can use might be to delay converting to DateTime object
        until necessary.

    Date::Manip
        Author: SBECK <https://metacpan.org/author/SBECK>

        Wow, there are surely a lot of negative reviews ... <br><br>First of
        all, Date::Manip has a long history. I used this module back in
        2001-2002, IIRC. Back then it was *the* swiss army of date/time
        manipulation, something you use when you want the most
        flexible/complete thing in Perl. True, it's slow, but it works.
        <br><br>But then things change. DateTime project was started, and
        now it is somewhat the de facto standard. It's more modern and far
        more modular than the monolithic Date::Manip (every timezone and
        language support and parsing/formatting modules shipped in one
        single distribution). <br><br>And then there's the 5.x -&gt; 6.x
        debacle. As someone who also sprinkle Perl 5.10 requirements to his
        CPAN modules, I can feel for the author. But the difference is, most



( run in 1.128 second using v1.01-cache-2.11-cpan-e1769b4cff6 )