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.

In reply to Re: Plugin-type architecture by doom
in thread Plugin-type architecture by thor

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.