eval results from the CPAN

Acme-CPANModules-Import-CPANRatings-User-stevenharyanto


my %FallbackPrereqs = (
  "File::Spec" => 0,
  "IO::Handle" => 0,
  "IPC::Open3" => 0,
  "Test::More" => 0,
  "strict" => 0
);


unless ( eval { ExtUtils::MakeMaker->VERSION(6.63_03) } ) {
  delete $WriteMakefileArgs{TEST_REQUIRES};
  delete $WriteMakefileArgs{BUILD_REQUIRES};
  $WriteMakefileArgs{PREREQ_PM} = \%FallbackPrereqs;
}

delete $WriteMakefileArgs{CONFIGURE_REQUIRES}
  unless eval { ExtUtils::MakeMaker->VERSION(6.52) };

WriteMakefile(%WriteMakefileArgs);

README view on Meta::CPAN

        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

README view on Meta::CPAN

        even nicer :-) <br><br>

    Data::Pond
        Author: ZEFRAM <https://metacpan.org/author/ZEFRAM>

        With due respect to the author, I fail to see the practical point of
        Pond. Pond (Perl-based open notation for data) is the Perl
        counterpart of JSON, except that implementation is currently only
        available in Perl (CMIIW), and &quot;Pond represents fewer data
        types directly&quot;. <br><br>Pond is pitched against Data::Dumper +
        eval, which is dangerous, but Data::Dumper + eval is by far not the
        only method available for serialization. Perl can do Storable, JSON,
        YAML, even PHP serialization format. <br><br>The documentation does
        not show what Pond looks like. <br><br>One cute thing about Pond is
        that you can check Pond syntax using a single regex. But apart from
        that, there's nothing compelling in using Pond to serialize data.

        Rating: 4/10

    File::Which
        Author: PLICEASE <https://metacpan.org/author/PLICEASE>

devdata/stevenharyanto view on Meta::CPAN




<img src="//cdn.perl.org/perlweb/cpanratings/images/stars-5.0.png" alt="*****">

</h3>



<blockquote class="review_text">
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...
</blockquote>


<div class="review_footer">
<p class="review_attribution">
<a href="/user/stevenharyanto">Steven Haryanto</a> - 2010-11-22T08:17:30
(<a href="/dist/Script-State#7874">permalink</a>)
</p>

<div class="helpfulq">

devdata/stevenharyanto view on Meta::CPAN




<img src="//cdn.perl.org/perlweb/cpanratings/images/stars-2.0.png" alt="**">

</h3>



<blockquote class="review_text">
With due respect to the author, I fail to see the practical point of Pond. Pond (Perl-based open notation for data) is the Perl counterpart of JSON, except that implementation is currently only available in Perl (CMIIW), and &quot;Pond represents few...
</blockquote>


<div class="review_footer">
<p class="review_attribution">
<a href="/user/stevenharyanto">Steven Haryanto</a> - 2010-09-02T02:47:18
(<a href="/dist/Data-Pond#7666">permalink</a>)
</p>

<div class="helpfulq">

lib/Acme/CPANModules/Import/CPANRatings/User/stevenharyanto.pm view on Meta::CPAN

package Acme::CPANModules::Import::CPANRatings::User::stevenharyanto;

use strict;

our $AUTHORITY = 'cpan:PERLANCAR'; # AUTHORITY
our $DATE = '2023-10-29'; # DATE
our $DIST = 'Acme-CPANModules-Import-CPANRatings-User-stevenharyanto'; # DIST
our $VERSION = '0.002'; # VERSION

our $LIST = {description=>"This list is generated by scraping CPANRatings (cpanratings.perl.org) user page.",entries=>[{description=>"\n(REMOVED)\n",module=>"Log::Any",rating=>undef},{description=>"\nProvides a thin/lightweight OO interface for \$?, ...

1;
# ABSTRACT: List of modules mentioned by CPANRatings user stevenharyanto

__END__

=pod

=encoding UTF-8

lib/Acme/CPANModules/Import/CPANRatings/User/stevenharyanto.pm view on Meta::CPAN

<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

=item L<Script::State>

Author: L<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...


=item L<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), &quo...
<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 ...


Rating: 8/10

lib/Acme/CPANModules/Import/CPANRatings/User/stevenharyanto.pm view on Meta::CPAN

<br><br>However, I like Data::Clone for its speed! It's several times faster than Clone or freeze+thaw. So hats up. Planning to use Data::Clone in future projects.
<br><br>Now if we can convince Goro to write a fast serializer/deserializer with compact output (essentially, a faster version of Storable), that would be even nicer :-)
<br><br>


=item L<Data::Pond>

Author: L<ZEFRAM|https://metacpan.org/author/ZEFRAM>

With due respect to the author, I fail to see the practical point of Pond. Pond (Perl-based open notation for data) is the Perl counterpart of JSON, except that implementation is currently only available in Perl (CMIIW), and &quot;Pond represents few...
<br><br>Pond is pitched against Data::Dumper + eval, which is dangerous, but Data::Dumper + eval is by far not the only method available for serialization. Perl can do Storable, JSON, YAML, even PHP serialization format.
<br><br>The documentation does not show what Pond looks like.
<br><br>One cute thing about Pond is that you can check Pond syntax using a single regex. But apart from that, there's nothing compelling in using Pond to serialize data.


Rating: 4/10

=item L<File::Which>

Author: L<PLICEASE|https://metacpan.org/author/PLICEASE>

t/00-compile.t view on Meta::CPAN

            $^X, @switches, '-e', "require q[$lib]"))
        if $ENV{PERL_COMPILE_TEST_DEBUG};

    my $pid = open3($stdin, '>&STDERR', $stderr, $^X, @switches, '-e', "require q[$lib]");
    binmode $stderr, ':crlf' if $^O eq 'MSWin32';
    my @_warnings = <$stderr>;
    waitpid($pid, 0);
    is($?, 0, "$lib loaded ok");

    shift @_warnings if @_warnings and $_warnings[0] =~ /^Using .*\bblib/
        and not eval { +require blib; blib->VERSION('1.01') };

    if (@_warnings)
    {
        warn @_warnings;
        push @warnings, @_warnings;
    }
}

( run in 1.898 second using v1.01-cache-2.11-cpan-98e64b0badf )