The contents of @ISA are what determines inheritance in Perl. use base sets @ISA and your assignment of @ISA= 'Exporter' overwrites that.

Are you sure that you really want to do both, export from your package and have your package a class? Usually, a class doesn't need to export anything, especially not its constructors.

Hi qhen,

...so why on earth should I bother with Exporter anyway?...

Maybe you should take a look at Exporter to start with.

Secondly, just like Corion said, I would re-frame, except on purpose ( and you really know what you want and what you are doing ), I will advice you don't export anything when doing OO in Perl.

You probably want to take a look into modern ways of doing OOP in Perl using Moose and it's cousins.
You might also want to look into perlootut and perlobj

There is no reason to use Moose or any heavy handedness for this. The other side of the coin here is that in the script using your module, you may simply use the constructor by calling it in its fully qualified name space. Once you have your blessed reference, there is no need to export any of the instance methods. For example the script using your new module would work perfectly fine if you omitted anything having to to with @INC or Exporter in the .pm:

use strict;
use warnings;
use MyClass::A ();

my $s = MyClass::A->new();
$s->serve();
[download]

The Perl module simply has do look like the following:

use strict;
use warnings

package MyClass::A;

sub new {
  my $pkg = shift;
  my $self = {};
  return bless $self, $pkg;
}

sub serve {
  my $self = shift;
  # .. do whatevs
}

1;
[download]

In the past Exporter was used to make it more convenient to load subroutines for use without having to deal with namespaces, but as it turns out using fully qualified namespaces is a really great thing to do. If you create a simple object via module using "traditional" Perl OOP, then you only have to type out the namespace once during construction. After that, the fact that the instance variable is blessed with the namespace means that you don't have to keep telling Perl what to use.

Thanks - that's what I needed to know. I've been trying to stick to the "modern" Perl way (ie, following recommendations by chromatic, conway, et al), and also trying to keep things simple and clean without having to resort to Moose, etc.

I've been using Exporter/@ISA and always wondered whether it was really needed as of Perl 5.8 (admittedly I have not spent the time to study the matter; time I often don't have) - the more syntactic cruft I can cut out, the better. I sometimes look at the relative elegance of Python and wish the same were true for Perl (which I love).

So, bottom line, I can simply exclude use Exporter; our @ISA = qw(Exporter); when creating a new class and/or inheriting from an existing, but still use:

our @EXPORT = qw(new serve);
our @EXPORT_OK = qw(foo);
[download]

to allow optional/selective exporting of methods.


UPDATE:

Someone else commented:

You need to use use Exporter; in your module to get the @EXPORT array into the calling script/module...

So, in order to use @EXPORT/@EXPORT_OK, I still need to use Exporter.

General rule of thumb: If you have @ISA or use base (with use parent being preferred to both of those nowadays) then you should not be using Exporter at all.

Beyond that, exporting sub-routines or variables from a library module (as opposed to an OO package) seems to be considered bad form today (though there could be legitimate reasons to do so in a $work environment.)

General rule of thumb: If you have @ISA or use base (with use parent being preferred to both of those nowadays) then you should not be using Exporter at all.

ok, but what if I want to allow the user of my New::Class to selectively import methods? in that case I need to use @EXPORT/@EXPORT_OK in order to do so.

Beyond that, exporting sub-routines or variables from a library module (as opposed to an OO package) seems to be considered bad form today (though there could be legitimate reasons to do so in a $work environment.)

I don't know what that means. To me, My::Package is synonymous with an OO class... unless I'm being dense and not understanding you correctly.

You are correct that Exporter is used to allow users to selectively import functions from a module. That said, you don't need to do that with an OO module. The object itself effectively does that when it is called on a method. There is no need to export (or make available for export) an OO method.

There is no need to export a function, though. Any sub-routine in a module can be called directly by means of using the package name, i.e. My::Package::some_function{}. This form of usage is becoming more popular that taking a chance on namespace collisions by exporting some_function().

It is the same with OO packages. A blessed object can call any method defined in the package without it being exported first: $obj->some_function() is effectively making a call to My::Package::some_function( $obj ) (but a blessed object has a few more properties, of course.)

There are things that can be done to essentially hide sub-routines from being available that way, but that is a different topic. :)

You must always remember that the primary goal is to drain the swamp even when you are hip-deep in alligators.

Each package contains a special array called @ISA. The @ISA array contains a list of that class's parent classes, if any.

You need to use use Exporter; in your module to get the @EXPORT array into the calling script/module, when anyone invokes a use declaration to load your module, it calls the import method from your module to fetch any symbols it needs into the package of the invoker. Your module (the one doing the exporting) can define the import method any way it pleases, but the standard way is to inherit the method from the Exporter class module.

The Exporter module serves as a base class for modules that wish to establish their own exports. Oddly, object-oriented modules typically don't use Exporter, since they don't normally export anything.

The import() method is invoked as a class method in your module: MyModule->import(LIST). However, since you didn't define an import method in your module, you'll automatically make use of the Exporter::import method through inheritance.