view release on metacpan or search on metacpan
Dist::Zilla::Plugin::Hook
Author: VDB <https://metacpan.org/author/VDB>
Great for debugging. Just whip up some code in dist.ini to e.g. dump
& print some stuffs, etc.
File::Tail::Dir
Author: JJSCHUTZ <https://metacpan.org/author/JJSCHUTZ>
Interesting features, but mooseware.
Rating: 6/10
Algorithm::Dependency
Author: ETHER <https://metacpan.org/author/ETHER>
Happily returns result when graph is cyclic (and thus proper
topological sorting cannot be done). See also Data::Graph::Util for
a simpler alternative. <br>
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> .
<br><br>One drawback of using Mojo::Base and Object::Simple is its
similar but slightly different and incompatible syntax with the Moo*
family, so your code is not "upgradable" to Moo or Moose
once you need more features. And often you'll end up wanting them,
e.g. one day you'll probably read about the wonders of method
modifiers (before, after, around), or roles, or wanting to have a
lazy constructor, or triggers, and so on. <br><br>I'd recommend
instead Mo. It's more lightweight than Object::Simple and you can do
default value, builder, ro/rw, required, even coercion. But the
features are modular and you only pay for what you use. And once you
need more features later, you normally should be able to just
replace 'use Mo' in your code with 'use Moo' or 'use Moose'.
<br><br>Of course, this point is moot if you don't care about
compatibility/upgradability to Moo*.
Rating: 6/10
Test::Needs
Author: HAARG <https://metacpan.org/author/HAARG>
Nice. API is more convenient to use than Test::Requires, especially
Ah, the many JSON implementation modules out there... <br><br>I
guess if you want to switch JSON implementation more easily with
JSON, JSON::PP, and JSON::XS, it's better to use
JSON::Tiny::Subclassable instead of JSON::Tiny, because the
interface is more similar to JSON{::XS,::PP}, although it's not
exactly the same. <br><br>
Devel::Confess
Author: HAARG <https://metacpan.org/author/HAARG>
Provides some more features compared to Carp::Always, like producing
stack trace even when exception is ref/object, color & dump
function arguments (so you don't need a separate Carp::Always::Dump
and Carp::Always::Color). Recommended. <br>
Carp::Always
Author: FERREIRA <https://metacpan.org/author/FERREIRA>
This module works well for string exceptions (e.g. die "some
message"), but for ref/object exceptions (e.g. die
[404,"Not found"] or die $some_object) it will simply
Date::Holidays itself does not use Moose. <br><br>Second, the
interface assumes that a country has a single set of holidays, which
is too restrictive in some cases. A more flexible/general interface
would allow adding more calendars based not only on country but also
religion, special community, organization, etc. And allow adding
custom calendars. <br>
Furl
Author: SYOHEX <https://metacpan.org/author/SYOHEX>
@Kira S (I wish cpanratings adds a feature to comment on a review):
<br><br>Comparing WWW::Mechanize with Furl is not really
apples-to-apples, since Furl does not support parsing/following
links or form processing. As the Furl POD itself suggests, Furl is
positioned as a faster alternative to LWP, not WWW::Mechanize.
Lingua::EN::Inflect
Author: DCONWAY <https://metacpan.org/author/DCONWAY>
Just add this review to link to Ben Bullock's
Lingua::EN::PluralToSingular if you need to go the other way
and stop). <br><br>For most Perl programmers familiar to the core
module Benchmark, I recommend looking at Benchmark::Dumb first
though. It has an interface like Benchmark (cmpthese() et all) but
with some statistical confidence.
Getargs::Long
Author: DCOPPIT <https://metacpan.org/author/DCOPPIT>
Nice idea, but some performance concerns. If you want to use
cgetargs (the compiled, faster version), you are restricted to the
getargs() interface, which only features checking for required
arguments and supplying default value. In which case you might as
well use Params::Validate directly as it's several times (e.g. 3-4x)
faster. <br><br>If you want to use the more featured xgetargs, there
is currently no compiled version. <br><br>All in all, I think users
should take a look at Params::Validate first.
Debug::Easy
Author: RKELSCH <https://metacpan.org/author/RKELSCH>
Not as easy as the name might claim. First of all, why do users need
to pass LINE explicitly for every call??? Other logging modules will
get this information automatically via caller(). <br><br>Levels are
a bit confusing: why is debug split to 2 (or 3)? <br><br>Not as
File::ReadBackwards
Author: PLICEASE <https://metacpan.org/author/PLICEASE>
At the time of this review, I find two modules for reading a file
backwards: File::Bidirectional (FBidi) and File::ReadBackwards
(FRB). <br><br>Both modules have roughly the same footprint and
minimal dependencies. Both provide OO as well as tie interface. Both
respect the $/ setting. <br><br>FRB pro's: <br> - FRB is 15-20%
faster than FBidi when reading backwards; <br><br>FRB con's: <br> -
does not offer the feature of reading forward as well, but of course
this is not the goal of the module. <br><br>FBidi's POD contains
information on benchmarks (it's roughly an order of magnitude slower
than raw Perl's open+read/diamond operator, still the case in 2014).
While FRB's POD contains information on how the thing works behind
the scenes. <br><br>In summary, both modules are roughly the same.
I'd prefer FRB unless in the rarer cases where I need bidirectional
reading. <br>
Rating: 8/10
File::Bidirectional
Author: KIANWIN <https://metacpan.org/author/KIANWIN>
At the time of this review, I find two modules for reading a file
backwards: File::Bidirectional (FBidi) and File::ReadBackwards
(FRB). <br><br>Both modules have roughly the same footprint and
minimal dependencies. Both provide OO as well as tie interface. Both
respect the $/ setting. <br><br>FBidi pro's: <br> - has the unique
feature of reading backward/forward and switch direction in the
middle; <br><br>FBidi con's: <br> - FBidi is 15-20% slower than
FBidi when reading backwards; <br> - reading forward is just as slow
as backward, so if you only need to read forward, obviously there's
no need to use this module; <br><br>FBidi's POD contains information
on benchmarks (it's roughly an order of magnitude slower than raw
Perl's open+read/diamond operator, still the case in 2014). While
FRB's POD contains information on how the thing works behind the
scenes. <br><br>In summary, both modules are roughly the same. I'd
prefer FRB unless in the rarer cases where I need bidirectional
reading. <br>
required beyond that are considered a bug and can be reported to me.
COPYRIGHT AND LICENSE
This software is copyright (c) 2023, 2018 by perlancar
<perlancar@cpan.org>.
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
BUGS
Please report any bugs or feature requests on the bugtracker website
<https://rt.cpan.org/Public/Dist/Display.html?Name=Acme-CPANModules-Impo
rt-CPANRatings-User-perlancar>
When submitting a bug or request, please include a test-file or a patch
to an existing test-file that illustrates the bug or desired feature.
devdata/perlancar view on Meta::CPAN
<img src="//cdn.perl.org/perlweb/cpanratings/images/stars-3.0.png" alt="***">
</h3>
<blockquote class="review_text">
Interesting features, but mooseware.
</blockquote>
<div class="review_footer">
<p class="review_attribution">
<a href="/user/perlancar">perlancar</a> - 2017-06-08T07:21:03
(<a href="/dist/File-Tail-Dir#13082">permalink</a>)
</p>
<div class="helpfulq">
devdata/perlancar view on Meta::CPAN
<img src="//cdn.perl.org/perlweb/cpanratings/images/stars-3.0.png" alt="***">
</h3>
<blockquote class="review_text">
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...
</blockquote>
<div class="review_footer">
<p class="review_attribution">
<a href="/user/perlancar">perlancar</a> - 2016-06-23T07:18:10
(<a href="/dist/Object-Simple#12814">permalink</a>)
</p>
<div class="helpfulq">
devdata/perlancar view on Meta::CPAN
<img src="//cdn.perl.org/perlweb/cpanratings/images/stars-5.0.png" alt="*****">
</h3>
<blockquote class="review_text">
Provides some more features compared to Carp::Always, like producing stack trace even when exception is ref/object, color & dump function arguments (so you don't need a separate Carp::Always::Dump and Carp::Always::Color). Recommended.
<br>
</blockquote>
<div class="review_footer">
<p class="review_attribution">
<a href="/user/perlancar">perlancar</a> - 2015-06-18T21:32:23
(<a href="/dist/Devel-Confess#12198">permalink</a>)
</p>
devdata/perlancar view on Meta::CPAN
(<a href="https://metacpan.org/release/Furl/">3.07</a>)
</h3>
<blockquote class="review_text">
@Kira S (I wish cpanratings adds a feature to comment on a review):
<br><br>Comparing WWW::Mechanize with Furl is not really apples-to-apples, since Furl does not support parsing/following links or form processing. As the Furl POD itself suggests, Fu...
</blockquote>
<div class="review_footer">
<p class="review_attribution">
<a href="/user/perlancar">perlancar</a> - 2015-05-13T00:09:32
(<a href="/dist/Furl#12168">permalink</a>)
</p>
<div class="helpfulq">
devdata/perlancar view on Meta::CPAN
(<a href="https://metacpan.org/release/Getargs-Long/">1.1004</a>)
</h3>
<blockquote class="review_text">
Nice idea, but some performance concerns. If you want to use cgetargs (the compiled, faster version), you are restricted to the getargs() interface, which only features checking for required arguments and supplying default value. In which case you mi...
</blockquote>
<div class="review_footer">
<p class="review_attribution">
<a href="/user/perlancar">perlancar</a> - 2015-03-23T00:19:32
(<a href="/dist/Getargs-Long#12106">permalink</a>)
</p>
<div class="helpfulq">
devdata/perlancar view on Meta::CPAN
<img src="//cdn.perl.org/perlweb/cpanratings/images/stars-4.0.png" alt="****">
</h3>
<blockquote class="review_text">
At the time of this review, I find two modules for reading a file backwards: File::Bidirectional (FBidi) and File::ReadBackwards (FRB).
<br><br>Both modules have roughly the same footprint and minimal dependencies. Both provide OO as well as tie inte...
- FRB is 15-20% faster than FBidi when reading backwards;
<br><br>FRB con's:
<br>
- does not offer the feature of reading forward as well, but of course this is not the goal of the module.
<br><br>FBidi's POD contains information on benchmarks (it's roughly an order of magnitude slower than raw Perl's open+read/diamond operator, s...
</blockquote>
<div class="review_footer">
<p class="review_attribution">
<a href="/user/perlancar">perlancar</a> - 2014-11-30T01:07:14
(<a href="/dist/File-ReadBackwards#12000">permalink</a>)
</p>
devdata/perlancar view on Meta::CPAN
<img src="//cdn.perl.org/perlweb/cpanratings/images/stars-4.0.png" alt="****">
</h3>
<blockquote class="review_text">
At the time of this review, I find two modules for reading a file backwards: File::Bidirectional (FBidi) and File::ReadBackwards (FRB).
<br><br>Both modules have roughly the same footprint and minimal dependencies. Both provide OO as well as tie inte...
- has the unique feature of reading backward/forward and switch direction in the middle;
<br><br>FBidi con's:
<br>
- FBidi is 15-20% slower than FBidi when reading backwards;
<br>
- reading forward is just as slow as backward, so if you only need to read forward, obviously there's no need to use this module;
<br><br>FBidi's POD contains information on benchmarks (it's roughly an order of magnitude slower than raw Perl's open+r...
</blockquote>
<div class="review_footer">
<p class="review_attribution">
<a href="/user/perlancar">perlancar</a> - 2014-11-30T01:06:06
(<a href="/dist/File-Bidirectional#11998">permalink</a>)
lib/Acme/CPANModules/Import/CPANRatings/User/perlancar.pm view on Meta::CPAN
package Acme::CPANModules::Import::CPANRatings::User::perlancar;
use strict;
our $AUTHORITY = 'cpan:PERLANCAR'; # AUTHORITY
our $DATE = '2023-10-29'; # DATE
our $DIST = 'Acme-CPANModules-Import-CPANRatings-User-perlancar'; # DIST
our $VERSION = '0.002'; # VERSION
our $LIST = {description=>"This list is generated by scraping CPANRatings (cpanratings.perl.org) user page.",entries=>[{description=>"\nI'm not sure this really "befits a ::Tiny distribution" just because it's a thin wrapper of something. P...
1;
# ABSTRACT: List of modules mentioned by CPANRatings user perlancar
__END__
=pod
=encoding UTF-8
lib/Acme/CPANModules/Import/CPANRatings/User/perlancar.pm view on Meta::CPAN
Author: L<VDB|https://metacpan.org/author/VDB>
Great for debugging. Just whip up some code in dist.ini to e.g. dump & print some stuffs, etc.
=item L<File::Tail::Dir>
Author: L<JJSCHUTZ|https://metacpan.org/author/JJSCHUTZ>
Interesting features, but mooseware.
Rating: 6/10
=item L<Algorithm::Dependency>
Author: L<ETHER|https://metacpan.org/author/ETHER>
Happily returns result when graph is cyclic (and thus proper topological sorting cannot be done). See also Data::Graph::Util for a simpler alternative.
<br>
lib/Acme/CPANModules/Import/CPANRatings/User/perlancar.pm view on Meta::CPAN
Author: L<MOB|https://metacpan.org/author/MOB>
Cool. Now you can create your own Camel Code with ease!
=item L<Object::Simple>
Author: L<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...
<br><br>One drawback of using Mojo::Base and Object::Simple is its similar but slightly different and incompatible syntax with the Moo* family, so your code is not "upgradable" to Moo or Moose once you need more features. And often you'll e...
<br><br>I'd recommend instead Mo. It's more lightweight than Object::Simple and you can do default value, builder, ro/rw, required, even coercion. But the features are modular and you only pay for what you use. And once you need more features later, ...
<br><br>Of course, this point is moot if you don't care about compatibility/upgradability to Moo*.
Rating: 6/10
=item L<Test::Needs>
Author: L<HAARG|https://metacpan.org/author/HAARG>
Nice. API is more convenient to use than Test::Requires, especially if you use subtests.
lib/Acme/CPANModules/Import/CPANRatings/User/perlancar.pm view on Meta::CPAN
Ah, the many JSON implementation modules out there...
<br><br>I guess if you want to switch JSON implementation more easily with JSON, JSON::PP, and JSON::XS, it's better to use JSON::Tiny::Subclassable instead of JSON::Tiny, because the interface is more similar to JSON{::XS,::PP}, although it's not ex...
<br><br>
=item L<Devel::Confess>
Author: L<HAARG|https://metacpan.org/author/HAARG>
Provides some more features compared to Carp::Always, like producing stack trace even when exception is ref/object, color & dump function arguments (so you don't need a separate Carp::Always::Dump and Carp::Always::Color). Recommended.
<br>
=item L<Carp::Always>
Author: L<FERREIRA|https://metacpan.org/author/FERREIRA>
This module works well for string exceptions (e.g. die "some message"), but for ref/object exceptions (e.g. die [404,"Not found"] or die $some_object) it will simply print/return the ref/object and thus no stack trace information ...
<br><br>See also Devel::Confess, which can handle ref/object.
<br><br>References:
lib/Acme/CPANModules/Import/CPANRatings/User/perlancar.pm view on Meta::CPAN
The idea is good, but a couple of things prevents me from using this interface.
<br><br>First, the use of TryCatch (which brings the Moose ecosystem) makes the startup overhead too high for my taste (about 0.5s on my PC). Which is rather unfortunate because Date::Holidays itself does not use Moose.
<br><br>Second, the interface assumes that a country has a single set of holidays, which is too restrictive in some cases. A more flexible/general interface would allow adding more calendars based not only on country but also religion, special commun...
<br>
=item L<Furl>
Author: L<SYOHEX|https://metacpan.org/author/SYOHEX>
@Kira S (I wish cpanratings adds a feature to comment on a review):
<br><br>Comparing WWW::Mechanize with Furl is not really apples-to-apples, since Furl does not support parsing/following links or form processing. As the Furl POD itself suggests, Furl is positioned as a faster alternative to LWP, not WWW::Mechanize.
=item L<Lingua::EN::Inflect>
Author: L<DCONWAY|https://metacpan.org/author/DCONWAY>
Just add this review to link to Ben Bullock's Lingua::EN::PluralToSingular if you need to go the other way (converting English noun from plural to singular).
<br><br>BTW, I don't like the interface either, and wonder why the Env module needs to be involved.
<br>
lib/Acme/CPANModules/Import/CPANRatings/User/perlancar.pm view on Meta::CPAN
Author: L<DCOPPIT|https://metacpan.org/author/DCOPPIT>
Nice alternative module for benchmarking with a different interface than Benchmark (marking portion of code to be benchmarked with start and stop).
<br><br>For most Perl programmers familiar to the core module Benchmark, I recommend looking at Benchmark::Dumb first though. It has an interface like Benchmark (cmpthese() et all) but with some statistical confidence.
=item L<Getargs::Long>
Author: L<DCOPPIT|https://metacpan.org/author/DCOPPIT>
Nice idea, but some performance concerns. If you want to use cgetargs (the compiled, faster version), you are restricted to the getargs() interface, which only features checking for required arguments and supplying default value. In which case you mi...
<br><br>If you want to use the more featured xgetargs, there is currently no compiled version.
<br><br>All in all, I think users should take a look at Params::Validate first.
=item L<Debug::Easy>
Author: L<RKELSCH|https://metacpan.org/author/RKELSCH>
Not as easy as the name might claim. First of all, why do users need to pass B<LINE> explicitly for every call??? Other logging modules will get this information automatically via caller().
<br><br>Levels are a bit confusing: why is debug split to 2 (or 3)?
<br><br>Not as flexible as it should be because the design conflates some things together. For example, most levels output to STDERR but some level (VERBOSE) outputs to STDOUT instead. The output concern and levels should've been separated. Another e...
lib/Acme/CPANModules/Import/CPANRatings/User/perlancar.pm view on Meta::CPAN
Author: L<PLICEASE|https://metacpan.org/author/PLICEASE>
At the time of this review, I find two modules for reading a file backwards: File::Bidirectional (FBidi) and File::ReadBackwards (FRB).
<br><br>Both modules have roughly the same footprint and minimal dependencies. Both provide OO as well as tie interface. Both respect the $/ setting.
<br><br>FRB pro's:
<br>
- FRB is 15-20% faster than FBidi when reading backwards;
<br><br>FRB con's:
<br>
- does not offer the feature of reading forward as well, but of course this is not the goal of the module.
<br><br>FBidi's POD contains information on benchmarks (it's roughly an order of magnitude slower than raw Perl's open+read/diamond operator, still the case in 2014). While FRB's POD contains information on how the thing works behind the scenes.
<br><br>In summary, both modules are roughly the same. I'd prefer FRB unless in the rarer cases where I need bidirectional reading.
<br>
Rating: 8/10
=item L<File::Bidirectional>
Author: L<KIANWIN|https://metacpan.org/author/KIANWIN>
At the time of this review, I find two modules for reading a file backwards: File::Bidirectional (FBidi) and File::ReadBackwards (FRB).
<br><br>Both modules have roughly the same footprint and minimal dependencies. Both provide OO as well as tie interface. Both respect the $/ setting.
<br><br>FBidi pro's:
<br>
- has the unique feature of reading backward/forward and switch direction in the middle;
<br><br>FBidi con's:
<br>
- FBidi is 15-20% slower than FBidi when reading backwards;
<br>
- reading forward is just as slow as backward, so if you only need to read forward, obviously there's no need to use this module;
<br><br>FBidi's POD contains information on benchmarks (it's roughly an order of magnitude slower than raw Perl's open+read/diamond operator, still the case in 2014). While FRB's POD contains information on how the thing works behind the scenes.
<br><br>In summary, both modules are roughly the same. I'd prefer FRB unless in the rarer cases where I need bidirectional reading.
<br>
lib/Acme/CPANModules/Import/CPANRatings/User/perlancar.pm view on Meta::CPAN
=head1 COPYRIGHT AND LICENSE
This software is copyright (c) 2023, 2018 by perlancar <perlancar@cpan.org>.
This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.
=head1 BUGS
Please report any bugs or feature requests on the bugtracker website L<https://rt.cpan.org/Public/Dist/Display.html?Name=Acme-CPANModules-Import-CPANRatings-User-perlancar>
When submitting a bug or request, please include a test-file or a
patch to an existing test-file that illustrates the bug or desired
feature.
=cut