This is related to a previous question of mine, but I've focussed my problem rather more closely, I hope.

I want to build a script with a nice API for plugins that lets people simply download a plugin, and it starts working automatically. (My end users aren't programmer types. They need stuff to be simple.) The plugins will extend, or replace, functions of the main script.

My current thoughts on architecture are as follows:
- any pluginable functions will call &replace() at their start and &extend() at the end.
- &replace() will search for plugins in the plugin directory. Plugins that want to replace the particular function will respond to the main plugin interface, and replace the main function with their own version.
- &extend() will do something similar, but as the main function has been called already, it will add to functionality rather than replace it.

Now this would work, but does it not kind of suck?

• I have to put calls to replace and extend in all of my subroutines.
• If I miss them out, the subroutine can't be pluginable. That's not futureproof.
• Adding subroutine calls everywhere will have a fairly big overhead.

Here's what I'd like to do - the Right Thing, I think.

• Use the package system.
• Plugins inherit from the main package. E.g.

  package MyPlugin;
  our @ISA = qw(TheMainPackageIReplace);
  ...
  [download]

  This inheritance works even without needing object-orientation, which is nice.
• The main script uses the plugins if they are available, otherwise it uses the main package, with its ancestor functions.

This would be most cool. I wouldn't have subroutine calls everywhere. I wouldn't have to specify which functions are pluginable. They all could be! And it uses the perl package system so I can use version numbers etc. for dependencies.

My problem is with point 3. Normally we use() a particular package, which then inherits from whatever. Now in this case, it's the reverse: we want to use "whatever package is available that fulfils this role". So if MainPackage is available, we use MainPackage; if MyPlugin is available, we use MyPlugin which inherits from MainPackage.

Now you see the problem? I don't know how to fix it so that the script knows which package to use(). Almost, I want to call the plugin something consistent and have it replace a default "plugin" which would inherit all its methods from the MainPackage ancestor. But this seems like it's going to involve a heavy overhead in resolving method calls by going up the inheritance tree. Plus, what about different plugins replacing different functions - ie multiple inheritance?

I seem to be trying to go against the way packages work. They inherit everything to one descendant from multiple ancestors. I want to hand function calls down to multiple descendants from one ancestor! Is there a better way? Or a neat solution? or even just a clever hack?

cheers
Dave

---

---

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! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

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:
	&		&
	<		&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.