I like Module::Pluggable too, I just started using it, myself. What it does for you is pretty simple, though: given a location in perl module namespace, it returns a list of all perl modules under that location.

What you do with that list is up to you though. In my first application, I wanted a set of pluggable storage backend modules, so the client code tries to require a "My::Stuff::Storage::YAML" or "My::Stuff::Storage::DBI", and the list from Module::Pluggable is helpful in checking for existence first... but on the other hand you can also just do an "eval require $module" and trap the error if it fails.

In my second application, I wanted to have an object with an extensible set of methods, where the client code specifies a method, and probably doesn't care which of a set of modules the method came from. For this application, I'm strongly considering just taking the list of plugin modules and pushing them into @ISA: yes, the dreaded "multiple inheritence".

The one big problem I can see with doing this is that later, if you need to modify some existing method, there doesn't seem to be any effective way of subclassing one of the plugins. If you create a My::Stuff::Plugin::Glue with a method "squirt" and then add a My::Stuff::Plugin::Glue::Super that inherits from it and also has a method "squirt", the plugin system might see one or the other definition of "squirt" depending on how the plugin list is sorted.

I've considered various solutions to this, but none strike me as terribly good ones. One point to consider is that it's important for the *client code* to be in control over which plugin module takes precedence: it would be very bad if existing code were broken without notice because someone added a new plugin module that solved their own immediate problem but is no good for the existing applications.

So I don't know about this one: maybe it's not even very helpful to think of this as a "plugin" system. Really I'm trying to handroll some half-baked system of inheritence where the client code doesn't have to specify a dependency and yet is in control of it's dependencies.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.