view release on metacpan or  search on metacpan

README  view on Meta::CPAN

        instead of the newer wp.getPost call (which understandably is only
        introduced in WordPress 3.4, while this module is last updated with
        WordPress 2.8.4). And apparently wordpress.com doesn't return
        post_content anymore when you use metaWeblog.getPost.
        <br><br>Luckily, performing XMLRPC request directly is easy enough.
        Just use XMLRPC::Lite and peruse the Wordpress documentation here:
        <a href="https://codex.wordpress.org/XML-RPC_WordPress_API"
        rel="nofollow">codex.wordpress.org/XML-RPC_WordPress...</a>

    Text::Levenshtein::Flexible
        Author: MBETHKE <https://metacpan.org/author/MBETHKE>

        My new favorite Levenshtein distance module. It's as fast (if not
        faster) than Text::Levenshtein::XS and can provide a speed boost if
        you don't care about distances above a certain limit. Which I think
        in many cases is true.

    CPAN::Changes
        Author: HAARG <https://metacpan.org/author/HAARG>

        Great and all, but one drawback is that it currently destroys
        original file's formatting in serialize().

    Module::Changes::ADAMK
        Author: ADAMK <https://metacpan.org/author/ADAMK>

        Any module from ADAMK should be interesting, including this one. But
        please take a look at CPAN::Changes for the de facto standard
        nowadays.

    Module::Metadata::Changes
        Author: RSAVAGE <https://metacpan.org/author/RSAVAGE>

        Like Module::Changes, this module also tries to use a more defined
        format for Changes. Sadly, it has not caught on. Please also take a
        look at CPAN::Changes which seems to be the de facto standard
        nowadays.

    Module::Changes
        Author: MARCEL <https://metacpan.org/author/MARCEL>

        In general I'm not opposed to the idea of this module. The included
        'changes' script is also pretty cool (which I'm trying to recreate,
        for CPAN::Changes). <br><br>Just pointing out that I believe this
        module has not really &quot;caught on&quot; among the CPAN
        community. What has, is, CPAN::Changes which is followed by many
        authors and even employed on MetaCPAN. <br>

    Archive::Tar::Wrapper
        Author: ARFREITAS <https://metacpan.org/author/ARFREITAS>

        Sadly there is not a single perfect Archive::Tar::* module out
        there. Either a module offers incomplete API, (was) buggy, or it is
        crippled/limited in some way. Plus, the modules are mostly
        incompatible with one another. And that's why TIMTOWTDI. <br><br>For
        the task of just listing files in an archive, for example, it seems
        only Archive::Tar and Archive::Tar::Wrapper are usable.
        Archive::Tar::Wrapper is fast (because it utilizes external C-based
        tar utility) and does not load all contents of an archive into
        memory, but requires writing to temporary files and of course
        requires a tar utility so portability to non-Unix systems might be
        an issue.

    Archive::Tar
        Author: BINGOS <https://metacpan.org/author/BINGOS>

        Sadly there is not a single perfect Archive::Tar::* module out
        there. Either a module offers incomplete API, (was) buggy, or it is
        crippled/limited in some way. Plus, the modules are mostly
        incompatible with one another. And that's why TIMTOWTDI. <br><br>For
        the task of just listing files in an archive, for example, it seems
        only Archive::Tar and Archive::Tar::Wrapper are usable. Archive::Tar
        is a core module, but relatively slow, and extracts all contents of
        an archive in memory so it's not workable for huge archives. <br>

    Hash::Util::Pick
        Author: PINE <https://metacpan.org/author/PINE>

        One can easily use this idiom instead: <br><br>$picked = { map
        {(exists $hash{$*} ? ($*=&gt;$hash{$*}):())} @keys }; <br><br>or:
        <br><br>$picked = { map {$*=&gt;$hash{$*}} grep {exists $hash{$*}}
        @keys }; <br><br>or (if you want non-existing picked keys to be
        created instead): <br><br>$picked = { map {$_ =&gt; $hash{$_}} @keys
        }; <br><br>but Hash::Util::Pick is implemented in XS and can be a
        few times faster than the above when the number of keys has reached
        thousands. So I guess this module has its uses.

    NetObj::IPv4Address
        Author: HEEB <https://metacpan.org/author/HEEB>

        Cons: more heavyweight (requires Moo), limited operations/methods,
        can only handle IPv4 and not IPv6. Pros: some operations are faster
        than competing modules, e.g. validation. See also: NetAddr::IP,
        Net::CIDR. <br>

    NetObj::MacAddress
        Author: HEEB <https://metacpan.org/author/HEEB>

        Aside from being Moo-based (which, makes it a bit more heavyweight
        and with more dependencies), doesn't yet offer anything extra or
        more methods compared to previously existing modules like
        NetAddr::MAC.

        Rating: 4/10

    Acme::AsciiArtinator
        Author: MOB <https://metacpan.org/author/MOB>

        Cool. Now you can create your own Camel Code with ease!

    Object::Simple
        Author: KIMOTO <https://metacpan.org/author/KIMOTO>

        I'd say in terms of footprint and runtime performance, this module
        is average (it's not the most lightweight nor the fastest pure-perl
        object system, not to mention against XS ones). See my
        Bencher::Scenarios::Accessors for a comparison, e.g. <a
        href="https://metacpan.org/pod/Bencher::Scenario::Accessors::Get"
        rel="nofollow">metacpan.org/pod/Bencher::Scenario::A...</a> and <a
        href="https://metacpan.org/pod/Bencher::Scenario::Accessors::Set"
        rel="nofollow">metacpan.org/pod/Bencher::Scenario::A...</a> .