|
Re: Clearing a namespace
by japhy (Canon) on Oct 04, 2000 at 08:08 UTC
|
And everyone forgot about Symbol::delete_package()...
Try perldoc Symbol.
$_="goto+F.print+chop;\n=yhpaj";F1:eval | [reply] |
reset (Re: Clearing a namespace)
by tye (Sage) on Oct 04, 2000 at 04:54 UTC
|
{
package TEST;
reset 'a-zA-Z';
}
But this is pure evil, of course.
-
tye
(but my friends call me "Tye") | [reply]
[d/l] |
Re (tilly) 1: Clearing a namespace
by tilly (Archbishop) on Oct 04, 2000 at 03:19 UTC
|
I wouldn't use import_names. If you find it handy then you are probably also not using strict and that is asking for trouble. Really, I think this is a serious, Don't Do That.
Just use a hash to store names, don't put them into a package. Hashes are easy to clear.
But answering your question, should you be doing something so silly, try the following:
*TEST:: = do {local *NEWGLOB};
But really, I suggest that you don't use that unless you can find from the online documentation (think perldoc) where that information is stored. And there is not a person that I know knows enough to tell you why that code works who would not also agree with my advice to use strict and use hashes. (I am not saying that such people don't exist, but I cannot identify any.) | [reply]
[d/l] |
RE: Clearing a namespace
by vladdrak (Monk) on Oct 04, 2000 at 04:44 UTC
|
If you _really_ wanted to wipe everything it seems like
this would work (and possibly have weird-fun consequences). Of course,
its not the Right Thing to do.
foreach $symname (sort keys %main::) {
local *sym=$main::{$symname};
if defined $sym {
undef $sym;
print "\$$symname was undefined\n";
}
if defined @sym {
undef @sym;
print "\@$symname was undefined\n";
}
if defined %sym {
undef %sym;
print "\%$symname was undefined\n";
}
}
-Vlad | [reply]
[d/l] |
RE: Clearing a namespace
by geektron (Curate) on Oct 04, 2000 at 03:17 UTC
|
once the namespace has gone out of scope, the variables are all cleared. if you're talking about CGI scripts, Perl's internal garbage collection cleans out the namespace when the script exits ( since all variables have gone out of scope, i.e. no references to them.)
i've always just used undef $foo when i've needed to explicitly blow away an instance of a variable.
you can always just re-assign values. coding $foo = 'blalal'; after $foo gets a value is appropriate.
if you need to blow away a namespace in the middle of a script i suspect there's something lacking in the design ( esp. if variable re-assignment doesn't fit the task).
UPDATE: merlyn has corrected me on terminology. namespaces don't go out of scope. variables in a namespace go out of scope. | [reply]
[d/l]
[select] |
|
|
A namespace doesn't "go out of scope" though. The original poster seems
to want to clear out some package before the script is over.
My simple advice: don't use the feature if you need to reuse the namespace.
-- Randal L. Schwartz, Perl hacker
| [reply] |
RE: Clearing a namespace
by cianoz (Friar) on Oct 04, 2000 at 03:21 UTC
|
The symbol table for a package happens to be stored in the
hash of that name with two colons appended. The main
symbol table's name is thus %main::, or %:: for short.
hope this helps.
| [reply]
[d/l] |
Re: Clearing a namespace
by Anonymous Monk on Oct 05, 2000 at 00:03 UTC
|
Appreciate the responses... for the record, I am what I once heard described as a 'perl Puritan' and have '-w' and 'use strict' in every script I write. There's some handy reasons for using import_names, mostly because it makes it much easier to handle param() values in here_docs.
The reason this is important to me is that I have a function generating a form... and so as to not get a ton of 'uninit'd value' warnings, at the top of this function I have a %values hash that does this:
%values = (
\t input_value => $ref->{ input_value } || $PARAM::input_value || ''
\t );
... and then the input element uses $values{ input_value } where appropriate. This lets you pass in a reference to a DBI statement fetchrow_hashref and covers your bases should there be some mixup. My question arose when I do any type of form verification and return the user to the form... under certain circumstances, I don't want %values to hold the param() info.
In any case, I appreciate the input... take care, folks.
markguy
| [reply]
[d/l] |