I have used both "roll-my-own" and Module::Pluggable with success. It really depends on what I was trying to do.

That said, I would probably be more inclined to go with M::P now since it offers more flexibility overall, even if not needed at the time. The use-cases I had involved finding what plugins were available so I could process a given input format with a given plugin, converting to an internal virtual format if it existed or bailing out otherwise.

Some of what I was doing could possibly be done using API Roles in Moose, instead.

Already the terminology "plugin" is hard to define but the alternative "addon" doesn't make it easier.

And I don't know what "double dispatch" is supposed to mean.

Could you tell us more about the concrete use case which triggered your question? =)

Module::Pluggable at least seems to easily cover the use cases I can (theoretically) think of...

I've written about plugins before, the gist of which is that autoloading plugins a la Module::Pluggable is often a bad idea.

In the long run, rather than automatically scanning for all installed plugins and using them, end users will get more predictable and reliable behaviour if you force them to provide an explicit list of plugins to load. Something like:

my $person = MyApp::Person->new(
   name    => 'Bob',
   age     => 33,
   plugins => [
      'FooCorp::Employable',
      'Web::Social::Contact',
   ],
);
[download]

I've had a todo for a while that I should write a follow up to my earlier article, showing how to use roles for extensibility. Until I write that, I refer you to MooseX::Traits, and the Role::Tiny documentation to get an idea of how this can be accomplished without Moose.

OK, now that you have updated your post with more information, I understand better what you are looking for, something like the http://search.cpan.org/~simonw/Module-Pluggable-4.8/lib/Module/Pluggable.pm module might be a good solution.

Another possibility might be to write a module (or use an existing one such as File::Find::xxx) that explores your directory and possibly subdirectories and you can then pass callback functions to this module to do the functional part of the job. Or even possibly passing an array or a hash of callback functions to the module.

Module::Pluggable can work, perhaps combined with File::HomeDir :)

For DIY, say you have : FLV::Info, Image::Info, MP3::Info ...

you could have MyStuff->load_plugins (Module::Load) ... MyStuff->register_plugin ... if( $thisplugin->do_run_run( $item,... ) ){ next } ....

Module::Pluggable arranges for this by naming convention so plugins don't need to register themselves (use MyStuff::Plugin; or MyStuff->register_plugin(__PACKAGE__) ), they just name themselves correctly :) (MyStuff::Plugin::Me)

Examples of this sort of thing can be found at mimetype,mimeopen, openit, Re^2: LWP to open a new browser window, Wx::Demo

It is a global DispatchTable :) Also useful food for thought The Architecture of Open Source Applications

Given the additional information I would agree that Module::Pluggable would be a viable way to go. You can scan in the plugins you have and build a hash of the kinds of file you can handle (with module names as values) and then call as needed for each file type as you encounter them. Each module could have a standard method that would "register" itself in the hash that could be called as part of the M::P search/init routine.

That is basically what I did for my primary use case. I had to take in various CSV and XML files and call the correct module to transform them into my internal format for further processing.

I would probably use the existing class-hierarchy capabilities of the Perl language, and perhaps the very-goodness of UNIVERSAL::require.

Your system would stipulate that all plugins must inherit from some base-class (perhaps “among others”) via a use base statement.   It would also require that the modules live in some specified location.   When a new plugin was requested, it would attempt to require the appropriate module, then, if successful in doing that, would perhaps call some class-method to initialize it.

Okay, for a brass-tacks example of what I am talking about, peruse http://search.cpan.org/~mkanat/RPC-Any-1.00/lib/RPC/Any/Server.pm#HOW_RPC_METHODS_ARE_CALLED which describes a similar “plugin” notion in the context of an RPC-server which loads request-handling modules on demand.   There are many others.   Study the source-code of “live examples” to see exactly how they did it.