Acme-CPANModulesBundle-PERLANCAR

 view release on metacpan or  search on metacpan

lib/Acme/CPANModules/PERLANCAR/Avoided.pm  view on Meta::CPAN

reason. Most of the modules wered used in my code in the past.

Using a <pm:Dist::Zilla> plugin
<pm:Dist::Zilla::Plugin::Acme::CPANModules::Blacklist>, you can make sure that
during building, your distribution does not specify a prerequisite to any of the
modules listed here. (You should make your own blacklist though).

_
    entries => [
        {
            module => 'Log::Any',
            summary => 'Startup overhead',
            description => <<'_',

After the 1.x version, I no longer prefer <pm:Log::Any> and have developed an
alternative called <pm:Log::ger>.

_
            alternate_modules => ['Log::ger'],
        },
        {
            'x.date' => '2017-09-08',
            module => 'List::MoreUtils',
            summary => 'License confusion',
            description => <<'_',

For more information, see
<https://www.reddit.com/r/perl/comments/6ymdez/what_are_the_background_details_pertaining_to_the/>.

Recent versions of <pm:List::Util> have implemented many functions from
<pm:List::MoreUtils>.

_
            alternate_modules => ['List::Util', 'List::SomeUtils', 'List::AllUtils'],
        },
        {
            module => 'Log::Any::IfLOG',
            summary => 'Retired workaround',
            alternate_modules => ['Log::ger'],
        },
        {
            module => 'File::Flock',
            summary => 'Too many deps',
            description => <<'_',

I used to use <pm:File::Flock> due to its simple interface. However, this module
depends on things like <pm:AnyEvent>, <pm:Data::Structure::Util>,
<pm:File::Slurp>, et al, all of which seem unnecessary. Nowadays I'm opting to
use <pm:File::Flock::Retry>, or just plain `flock()`.

_
            alternate_modules => ['File::Flock::Retry'],
        },
        {
            module => 'File::Slurp',
            summary => 'Not encoding-friendly',
            description => <<'_',

File::Slurp was created (1996) before Perl IO layers (5.8, 2002) and its API
does not handle encoding properly. See:
<http://blogs.perl.org/users/leon_timmermans/2015/08/fileslurp-is-broken-and-wrong.html>
or discussion on RT.

_
            alternate_modules => ['File::Slurper'],
        },
        {
            module => 'File::Slurp::Tiny',
            summary => 'Discouraged by the author',
            description => <<'_',

The author of File::Slurp::Tiny has discouraged its use and recommends his newer
module <pm:File::Slurper>.

_
            alternate_modules => ['File::Slurper'],
        },
        {
            module => 'Exporter::Lite',
            summary => 'Unnecessary, use Exporter instead',
            description => <<'_',

I used to use this module because I didn't know that <pm:Exporter> (since perl
5.8.3, 2004) can also be used without subclassing, i.e. instead of:

    use Exporter;
    our @ISA = qw(Exporter);
    our @EXPORT = (...);

you can also use it like this:

    use Exporter qw(import);
    our @EXPORT = (...);

Hence, this module (first released in 2001) is no longer necessary. Besides,
this module has a worse startup overhead than <pm:Exporter> *and* has less
features. So there is absolutely no reason to use it.

_
            alternate_modules => ['Exporter'],
        },
        {
            module => 'JSON',
            summary => 'Somewhat broken',
            description => <<'_',

JSON.pm is a discouraged module now, due to its somewhat broken backend handling
and lack of support for <pm:Cpanel::JSON::XS>. Consider switching to
<pm:JSON::MaybeXS> or perhaps just <pm:JSON::PP>.

_
            alternate_modules => ['JSON::MaybeXS', 'JSON::PP', 'Cpanel::JSON::XS'],
        },
        {
            module => 'JSON::XS',
            summary => '',
            description => <<'_',

<pm:Cpanel::JSON::XS> is the fork of <pm:JSON::XS> that fixes some bugs and adds
some features, mainly so it's more compatible with <pm:JSON::PP>. See the
documentation of <pm:Cpanel::JSON::XS> for more details on those.

lib/Acme/CPANModules/PERLANCAR/Avoided.pm  view on Meta::CPAN


=over

=item L<Log::Any>

Startup overhead.

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

After the 1.x version, I no longer prefer L<Log::Any> and have developed an
alternative called L<Log::ger>.


Alternate modules: L<Log::ger>

=item L<List::MoreUtils>

License confusion.

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

For more information, see
L<https://www.reddit.com/r/perl/comments/6ymdez/what_are_the_background_details_pertaining_to_the/>.

Recent versions of L<List::Util> have implemented many functions from
L<List::MoreUtils>.


Alternate modules: L<List::Util>, L<List::SomeUtils>, L<List::AllUtils>

=item L<Log::Any::IfLOG>

Retired workaround.

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

Alternate modules: L<Log::ger>

=item L<File::Flock>

Too many deps.

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

I used to use L<File::Flock> due to its simple interface. However, this module
depends on things like L<AnyEvent>, L<Data::Structure::Util>,
L<File::Slurp>, et al, all of which seem unnecessary. Nowadays I'm opting to
use L<File::Flock::Retry>, or just plain C<flock()>.


Alternate modules: L<File::Flock::Retry>

=item L<File::Slurp>

Not encoding-friendly.

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

File::Slurp was created (1996) before Perl IO layers (5.8, 2002) and its API
does not handle encoding properly. See:
L<http://blogs.perl.org/users/leon_timmermans/2015/08/fileslurp-is-broken-and-wrong.html>
or discussion on RT.


Alternate modules: L<File::Slurper>

=item L<File::Slurp::Tiny>

Discouraged by the author.

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

The author of File::Slurp::Tiny has discouraged its use and recommends his newer
module L<File::Slurper>.


Alternate modules: L<File::Slurper>

=item L<Exporter::Lite>

Unnecessary, use Exporter instead.

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

I used to use this module because I didn't know that L<Exporter> (since perl
5.8.3, 2004) can also be used without subclassing, i.e. instead of:

 use Exporter;
 our @ISA = qw(Exporter);
 our @EXPORT = (...);

you can also use it like this:

 use Exporter qw(import);
 our @EXPORT = (...);

Hence, this module (first released in 2001) is no longer necessary. Besides,
this module has a worse startup overhead than L<Exporter> I<and> has less
features. So there is absolutely no reason to use it.


Alternate modules: L<Exporter>

=item L<JSON>

Somewhat broken.

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

JSON.pm is a discouraged module now, due to its somewhat broken backend handling
and lack of support for L<Cpanel::JSON::XS>. Consider switching to
L<JSON::MaybeXS> or perhaps just L<JSON::PP>.


Alternate modules: L<JSON::MaybeXS>, L<JSON::PP>, L<Cpanel::JSON::XS>

=item L<JSON::XS>

.

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



( run in 2.195 seconds using v1.01-cache-2.11-cpan-cdf2f3d4e48 )