Your method works, and is in no way bad. If you need to load code into your package,  evaling it is the standard, as far as I know... (You'll see NMS Inlines a module, and then evals the require.)

However, there are other ways to do it, if you don't like how you're package is working right now:

Update: Errr... Forgot the best way to do things, in my opinion. Here it is: If your plugin module uses only subroutines, you can either create a custom import routine or use Exporter.pm to export your subroutines. This will work even if you have some special package variables, but I believe you'll have to specify those variables for export, and they will become package global to your new package (meaning they'll be like ours, not mys ). Look at perldoc -f import as well.

Otherwise, if this doesn't work, you could always runtime load  @ISA. This may be constituted as a sin:

If you do that, I would just put:

eval { @YOURapp::ISA = $mod };  # May *seem* mad, but I deem it permis
+sible here
[download]

Or whatever the applicable set of modules is.
I like shotgunefx's advice of an OO rapper, though. That's what I for code I need to be accessible. If you don't feel like writing such a rapper, you could also look into an autoload function that got the variables for you. This would probably be easiest and best done by creating a hash of variable's references you wanted to share with other packages, and then sending them with an autoload of some sort.

However, it's easiest and probably best to just use package variables. Is there any specific reason not to do so? If so, is that reason large enough to use a more 'exotic' method for getting your variables?

Gyan Kapur
gyan.kapur@rhhllp.com