but I was wrong.local *private::package::; # time passes $saved{$some_name} = \*private::package::;
As for the underlying question though, your description of what you are doing sets off warning flags for me. Why not scoop out the body of the scripts into modules, turn the scripts into wrappers, and then call the module in your code? What if a script makes an assumption and does something like call exit? Why do you need to have the globals in your current package, can you redesign to not need that? If you have any control over what globals you need from the script, why not eval each script into its own package, then in your second loop alias just the globals that you need from the scripts?
The exit question is a serious gotcha. The other suggestions are alternate ways of solving your likely problem. I have found valid uses for all of the other suggestions. The one with each getting their own package was for configuration loading - there are very few other places where I would even consider that. The idea of scooping things into modules is my first recommendation.
Now there could be things I don't know that make all of these ideas bad. But my gut feeling is that you don't need to use your current design, and that using it you will run into further issues - it just smells like a bad hack.
In reply to RE (tilly) 3: package namespace manipulation
by tilly
in thread package namespace manipulation
by knight
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |