I don't think there's much of a practical difference. It's shorter and it doesn't add anything to the @ISA array, meaning that there's a shorter inheritance tree for method resolution if you're doing a lot of multiple inheritance.

I think the original subclassing approach was just a bad design choice, but now we're stuck with it if we want to be backwards compatible. But since that isn't an issue for some people (e.g. people writing specifically for desireable features of Perl 5.8, like Unicode), they have the option of moving to the better design.

Arg. I just tried with my real code running perl 5.8.8, and it does actually a difference : use base 'Exporter' works, use Exporter doesn't (??!?!?). The module is absolutely trivial :

package DBtools;

use strict;
use warnings;

use DBI;
use Exporter;

our @EXPORT=qw( dbconnect );

#sub definition
sub dbconnect {
    my $config = shift;

    my $dbh = DBI->connect(
        'DBI:'
          . $config->param('dbdriver')
          . ':dbname='
          . $config->param('dbname')
          . ';host='
          . $config->param('dbhost'),
        $config->param('dbuser'),
        $config->param('dbpassword'),
        { PrintError => 0, RaiseError => 1, AutoCommit => 0 }
      );

    return ($dbh);
}

1;
[download]

I'm going to stick with "use base" for now :/

My bad. As per the Exporter docs, you need to request import explicitly. (You can see how rarely I actually do that!)

package Blarg;

use Exporter qw( import );
[download]

I updated my earlier post.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.