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?

As you originally were talking about lexically scoped variables (i.e. variables declared with my), yes. There is a big difference. Lexicals are only visible from their declaration to the end of their enclosing block, eval, or file. Lexicals do not have symbol table entries. Global variables, such as those declared with our, are visible everywhere and do have symbol table entries. Your mention of "::main" was reminiscent of symbol tables (though "main::" would have made a bit more sense.)

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.

Variables as well as functions will run the risk of being clobbered. Warnings will help catch redefined subs but not variables.

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.

I think you missed the point of my assertion. I wasn't suggesting that the notion of plugins wasn't useful. I was suggesting that, if you are going to let your plugins traipse all over your main program, then you are better off not using them. I say so because that approach is likely to cause a maintenance nightmare.

* 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.

I simply meant that one way to share information between the main program and the plugin is to call subs that are implemented in main from the plugin. The concept is pretty simple but I wasn't very clear. Here's a quick example:

sub f {
    print "Data from plugin: $_[0]\n"; 
    return 'foo';
}; 

package Plugin; 
my $r = main::f('bar'); 
print "Data to plugin: $r\n"
[download]

See? It's so simple that I almost felt silly writing that. :-) A more useful example of this might be requiring your plugin to always register itself with the main program by calling main::register_plugin() or some such.

As you say you'll only use a single "plugin" at a time, I'm not convinced that simply having multiple branches of execution wouldn't make more sense in your case. It sounds like you really just want some code to be loaded on demand and you could implement that via AutoLoader if necessary. I don't really know what functionality the various plugins provide though so it's hard to form an opinion.

-sauoq
"My two cents aren't worth a dime.";