use strict;
use warnings;
package Perl::Critic::Policy::Tics::ProhibitUseBase 0.010;
# ABSTRACT: do not use base.pm

#pod =head1 DESCRIPTION
#pod
#pod   use base qw(Baseclass);
#pod
#pod You've seen that a hundred times, right?  That doesn't mean that it's a good
#pod idea.  It screws with C<$VERSION>, it alters (for the worse) the exceptions
#pod reported by failure-to-require, it doesn't let you call the base class's
#pod C<import> method, it pushes to C<@INC> rather than replacing it, and it uses
#pod and documents interactions with L<fields|fields>, which can lead one to believe
#pod that fields are even remotely relevant to modern (or any!) development of Perl
#pod classes.
#pod
#pod There are a lot of ways around using C<base>.  Pick one.
#pod
#pod =head1 WARNING
#pod
#pod This policy caused a bit of controversy, largely in this form:
#pod
#pod   These behaviors are either correct or can be worked around, and using base.pm
#pod   protects you from the problem of remembering to load prereqs and from
#pod   setting @INC at runtime.
#pod
#pod These are true statements.  My chosen workaround for all these problems is to
#pod I<not use base.pm>.  That doesn't mean it's a good idea for you, or anyone
#pod else.  Heck, it doesn't mean it's a good idea for me, either.  It's just my
#pod preference.  As with all Perl::Critic policies, you should decide whether it's
#pod right for you.
#pod
#pod =cut

use Perl::Critic::Utils;
use parent qw(Perl::Critic::Policy);

my $DESCRIPTION = q{Use of "base" pragma};
my $EXPLANATION = q{Don't use base, set @INC or use a base.pm alternative.};

sub default_severity { $SEVERITY_LOW             }
sub default_themes   { qw(tics)                  }
sub applies_to       { 'PPI::Statement::Include' }

sub violates {
  my ($self, $elem, $doc) = @_;

  return unless $elem->module eq 'base';

  # Must be a violation...
  return $self->violation($DESCRIPTION, $EXPLANATION, $elem);
}

1;

__END__

=pod

=encoding UTF-8

=head1 NAME

Perl::Critic::Policy::Tics::ProhibitUseBase - do not use base.pm

=head1 VERSION

version 0.010

=head1 DESCRIPTION

  use base qw(Baseclass);

You've seen that a hundred times, right?  That doesn't mean that it's a good
idea.  It screws with C<$VERSION>, it alters (for the worse) the exceptions
reported by failure-to-require, it doesn't let you call the base class's
C<import> method, it pushes to C<@INC> rather than replacing it, and it uses
and documents interactions with L<fields|fields>, which can lead one to believe
that fields are even remotely relevant to modern (or any!) development of Perl
classes.

There are a lot of ways around using C<base>.  Pick one.

=head1 PERL VERSION

This library should run on perls released even a long time ago.  It should work
on any version of perl released in the last five years.

Although it may work on older versions of perl, no guarantee is made that the
minimum required version will not be increased.  The version may be increased
for any reason, and there is no promise that patches will be accepted to lower
the minimum required perl.

=head1 WARNING

This policy caused a bit of controversy, largely in this form:

  These behaviors are either correct or can be worked around, and using base.pm
  protects you from the problem of remembering to load prereqs and from
  setting @INC at runtime.

These are true statements.  My chosen workaround for all these problems is to
I<not use base.pm>.  That doesn't mean it's a good idea for you, or anyone
else.  Heck, it doesn't mean it's a good idea for me, either.  It's just my
preference.  As with all Perl::Critic policies, you should decide whether it's
right for you.

=head1 AUTHOR

Ricardo SIGNES <cpan@semiotic.systems>

=head1 COPYRIGHT AND LICENSE

This software is copyright (c) 2007 by Ricardo SIGNES.

This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.

=cut
