Maintaining Symbol table state.

Ovid has asked for the wisdom of the Perl Monks concerning the following question:

In a recent Usenet post, a person had a problem with an application that loads Perl, produces reports, but doesn't unload Perl. As a result, some of the Perl libraries that he uses have global variables that stick around and he wants to know to to reset those to their pristine state. After some discussion in the CB, Fletch suggested reset. It seems good, but it would also overwrite any default values. Ignoring this for a moment, the CB Monks came up with the following (assuming the variables are all lower case):

my @package = qw/ foo bar foo::bar /;

foreach my $package ( @packages ) {
    eval "package $package; reset 'a-z'";
}
[download]

That seems to work, but I lose the initial state of the package variables. Anyone know of a simple way to do that without walking through symbol tables, checking the ref results and grabbing the values?

I'm actually thinking this might be a nifty module to reset symbol tables to their initial state rather than just clear them out.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Comment on Maintaining Symbol table state. Download Code

Replies are listed 'Best First'.
Re: Maintaining Symbol table state. by chromatic (Archbishop) on Dec 07, 2001 at 00:00 UTC
Is something preventing the use of `local $foo = $foo?;`?	[reply] [d/l]
(Ovid) Re: Re: Maintaining Symbol table state. by Ovid (Cardinal) on Dec 07, 2001 at 00:38 UTC
Hadn't considered that because I haven't seen this person's application. Here's part of what he wrote: If only life were so simple as to add "use strict" and declare variables. Unfortunately various of the Perl libraries we use do not pass this test and some of them make use of global variables. This could no doubt be fixed, but at the risk of breaking a zillion other sites. I could go on at length about some of the architectural problems, but unloading libraries which "require" in a context sensitive manner is another problem. Essentially, this person has been handed a C++ application that loads Perl for report processing and, for some reason, can't unload Perl, thus having the globals hang around for subsequent reports and corrupting output. I have no idea how extensive the Perl is, so I don't know if simply using local for the package variables is an option. If you want to see the full scope of the dilemma, check out the usenet post. Cheers, Ovid Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.	[reply]