I tested and doing it in INIT works as you'd expect: import is called when the module is used, thereby replacing the function before the base one being replaced is defined. So the base ends up replacing the plug-in. But INIT is called right before execution so it does the job.

Regarding the evilness of this: Playing around like this is one of the ways I learned how Perl works. You will no doubt experience several lightbulbs going on as try different approaches, which is a good thing. Just think about your clients, the interfaces they use, and how much you may be bending standard views of the world before you turn what you play with into production code.

Ah, cool. Thanks!

Yeah, i understand. Im not really expecting this to become widespread, i just think its an interesting idea.

Thanks again.

Correct me if im wrong, but INIT is run once, correct?
If multiple 'use's to Plugin.pm are made, then do problems arise?

Another thing to consider, is using the Safe module (with everything turned on perhaps) to load the plugins into a certain namespace. And then use that namespace for the parts of your code you want the plugins to overwrite. That way, you can even still publish an interface, but each plugin can only see the plugin-accessible part of the namespace.

use Safe;
my $cpt = Safe->new( 'PluginNamespace' );
$cpt->deny_only();
$cpt->rdo( PLUGINFILENAME );
[download]

I use Safe alot, but rarely for what it was intended for...

Hmm, sounds like it might work. I'll look into that.
Thanks.

Even though the dispatch-ness sounds pretty cool, my goal is to have the base module have all the subs.

Understood. The advantage of using method dispatch over stash mangling is that you can have multiple instances which don't conflict.

  package Foo;
  sub shared { print "Shared method" }
  sub foozle { print "Foo's foozle" }

  package Bar;
  sub foozle { print "Bar's foozle" }

  package Blip;
  sub foozle { print "Blip's foozle" }

  package FooBar;
  @ISA = qw( Bar Foo );

  package FooBlip;
  @ISA = qw( Blip Foo );
[download]

With that kind of setup, you can choose which set of plugins you want to have active, and can have one part of your code use one plugin while another part does not.

  package main;

  $package = 'Foo';
  $package->shared();
  $package->foozle();      # Calls Foo's foozle

  $package = 'FooBar';
  $package->shared();
  $package->foozle();      # Calls Bar's foozle
[download]

This approach also lets you dynamically stack your "plugins" so that a method in one of them can call NEXT and get the results of the next method up the chain; see my earlier article for details of this technique.

Interesting, but not exactly what im looking for.


Editing your code, I'd like something like this:
(i get the multiple inheritance part, but the functionality is different, top-most subs are not accessed through the base module)

  package Foo;
  use Plugin 'Bar';
  sub shared { print "Shared method" }
  sub foozle { print "Foo's foozle" }

  package Bar;
  our @PLUGIN_SUBS = qw(foozle);
  sub foozle { print "Bar's foozle" }

  # omitting Blip..
  #package Blip;
  #sub foozle { print "Blip's foozle" }

  #=======================
  
  package main;

  $package = 'Foo';
  $package->shared();
  $package->foozle();      # Calls ***Bar's*** foozle
[download]

From what i see theres no other way to have things work that way.

Now this doesnt allow for having two instances of a plugin tree with the same base (at the moment), unfortunately.