You really should allow interaction between your main program and your plugins via a well-defined API, not by jumping through hoops to get the plugin code evaluated in your main program's file scope.

 True I should. However I'm not really sure how to go about doing that. In the C++ version of the code which I'm re-coding in Perl I could enforce this through inheritence, and passing around pointers to abstract base classes. At the moment I'm unsure how I should handle this in perl.

(Note that this has nothing to do with the main package scope as your reference to "::main scope" attempts to imply.)

 I apologise for my imprecise wording, I was under the impression that things at file scope in the main file/script would be at main scope. Are the two not the same? (Assuming the abscence of a 'package' statement)

Your plugins will all be one unfortunate identifier choice away from clobbering your main program or another plugin.

 True, the plugin functions will clobber identifiers with the same name in the main scope; but this will be caught quickly by the perl interpretter.

 By design only one plugin is ever loaded in the execution of the main script. (There is forking involved and one forked child will ever attempt to load one plugin)

You might make such a system work as long as you are the only one writing plugins but that defeats the purpose and, in that case, you might as well just extend the main program directly.

 I'm not sure I agree with that 100%. Consider the case of something like a webserver which wanted to generate, and serve, realtime statistics to a small number of clients.

 Writing the statistics display as a CGI script (or plugin) which would simply serve the last 100 lines from the access.log file is conceptually simpler than adding the functionality in the core of the server.

 That's a fairly similar situation to how my plugins are used. Yes they could be in the core of the script but having them as external plugins does simplify the core of the script.

* Calling subs defined in the plugins,

 This happens, there are only three functions exported by each plugin, as hinted at in my original code snippet.

* Providing subs which are called by the plugins,

 I'm not 100% sure how this could be enforced or achived, if you had the time I'd appreciate a small example, or a pointer to something discussing this more.

* Managing documented global variables.

 This is already done, and such interactions are very minimal.

 Thanks for taking the time to respond - I'm certainly open to better ways of coding this system.

Steve
---
steve.org.uk

In reply to Re: Coding perl a plugin system? by skx
in thread Coding perl a plugin system? by skx

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.