This is trivial to break:

require MyOOModule;
use base 'MyOOModule';
[download]

Or just use the module in more than one place. Only the first place will have the potential to do this auto-import.

It'd make more sense to change your import() to be able to set the caller's inheritance:

use MyOOModule qw( -ISA ... );
[download]

Or however you want to name the option.

Hrm, that's an interesting idea. That second idea will work for my purposes.

---

Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart

Roughly similar in effect to

           package Baz;
           BEGIN {
               require Foo;
               require Bar;
               push @ISA, qw(Foo Bar);
           }
[download]

package LikeOOModule;
use base 'MyOOModule';

sub foo {
  my $self = shift;
  if ($self->mode == $self->OO_THIS) { ... }
  elsif ($self->mode == $self->OO_THAT) { ... }
}
[download]

Solves the problem and allows for overloading, if necessary. Don't let the fact that it's currently a constant blind you to the fact that you may want to override it later. (Particularly in testing, I've found.)

But that's why I'm using constants, because their values shouldn't change. The concept of constant folding disappears when you do what you showed.

Still, I agree with other people that this is an easily broken system, and goes against the definition of base. So I think I'll suck it up and write MyOOClass->import and be done with it all.

---

Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart

Won't this fail if a second module tries to use base?

You could make your own customised class which follows the conventions of "use":

use baseimp
  'Foo' => ['Import', 'some', 'stuff'],
  'Bar', # import defaults
  'Buz' => [] # don't call import, just like use Buz ()

package baseimp;

use base 'base'; # :)

# unfortunately most modules (including base.pm) are hardwired to use 
+caller(0) so trickery is needed

use Sub::Uplevel;

sub import
{
  my $pkg = shift;

  $base_import = UNIVERSAL::can(__PACKAGE__, "SUPER::import");
  while (my $class = shift)
  {
    # let base do it's thing
    uplevel(1, $base_import, $class);

    # now do what use would do
    my $imp_args;

    if (ref($_[0]))
    {
      $imp_args = shift;
      undef $imp_args unless @$imp_args;
    }
    else
    {
      $imp_args = [];
    }

    if ($imp_args)
    {
      $class_import = UNIVERSAL::can($class, "import");
      uplevel(1, $class_import, $class, @$imp_args);
    }
  }
}
[download]

So without any array refs, this works exactly like base except it _does_ import stuff, when you add array refs you get to control the imports exactly as with a normal use.

Your &uplevel call don't work if base is compiled before you compile Sub::Uplevel, which it is, and you can't ever guarentee to load Sub::Uplevel before base from within your module, no matter how hard you try, which is annoying. Perl needs a real uplevel().

Anyhow, while this is a fun module, I fail to see what good it really does. I'd just stick with

use base 'Foo'; use Foo qw/ Import some stuff /;
use base 'Bar'; use Bar;
use base 'Buz'; use Buz ();
[download]

It's a few extra chars, but I and everyone else will know exactly what happens. I guess this is one of those "just because you can doesn't mean you should" situations Perl constantly provides us with. :-)

ihb

See perltoc if you don't know which perldoc to read!

OK, so forget uplevel and just reimplement what base actually does. It's a pity base.pm didn't do it right from the start. If you're going to act like "use" then you should do it properly.

As for a just a few characters, I really have a problem with that. I don't mind a few characters extra for some things but this is perfect case of when I do mind because the few characters are a repetition of information (not just, say, some extra syntax).

That means that if I need to change the base class, I need to remember to change both occurrences. This breaks the rule of having 1 source for every piece of information and leads to subtle errors. In this case it's fairly easy to keep them in sync as they're beside each other but in another way that makes it even worse because it would be so easy to fix.

Cool. My only nit with it (and it's a nano-nit) is that $pkg is being passed as an arg to export_to_level, which gives the mistaken impression that it means something, when in fact that argument is ignored. Do you happen to know of plans to make that argument actually meaningful in the not-too-distant future? If not, I'd make that line

  __PACKAGE__->export_to_level($level, undef, @EXPORT)
    if $pkg;
[download]

If you want to inherit, use base. If you want to import, call import. (If you want to import constants and benefit from constant folding, use use to import.) Those are the simple ideas.

use MyOOModule qw/ THE CONSTANTS /;
use base 'MyOOModule';
[download]

Personally I almost always name what I import, so that when I or someone else return to the code, it'll be clear from where a function was imported.

For similar reasons I'd like to advice against using import to set up inheritance unless you really have to, since that is what base is for, and it'll surprise people who read your code.

ihb