Don't ask to ask, just ask | |
PerlMonks |
Re: Coding perl a plugin system?by skx (Parson) |
on Dec 15, 2002 at 23:16 UTC ( [id://220076]=note: print w/replies, xml ) | Need Help?? |
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 Section
Seekers of Perl Wisdom
|
|