[EMAIL PROTECTED] wrote:
>On Mon, Apr 17, 2000 at 01:33:08PM -0600, Jason Terry wrote:
>> This is the first i have seen "delete" referenced. What does it do?
>> How is it used?
>>
>> Thank you
>> -Jason
>
>It's the stack cleaner... but it only works for scalars, and maybe
>arrays, but its better for arrays and hashes to do the following at
>the bottom of each code block in registry scripts. (True good note)
>
>@somearray = ();
>%somehash =();
>delete $somescalar;
>(and don't forget untie :-> )
>
>Basically it will clean up *most* of the memory taken up by these
>variables.
There are some serious misconceptions at work here. First of all, delete()
can't be used on a scalar. I think you're thinking of undef(). And second,
the memory de-allocation is very good, and very precise, and doesn't work any
differently under mod_perl than it does under regular Perl. Why? Because
mod_perl *IS* regular Perl. It's simply a Perl interpreter that lasts a long
time.
Code run under Apache::Registry has some additional things it needs to
consider, since the entire "CGI" will be wrapped up inside a subroutine,
creating trapped lexicals (the guide is actually incorrect in calling them
closures). But the guide suggests several workarounds, all of which will get
the job done.
[ By the way, Stas - is there a CVS version of the guide that I can make
patches against? I found a few inaccuracies. ]
Well-written code will get its variables cleaned up exactly when and how it
wants it cleaned up. This is true under mod_perl or standalone Perl.
Sometimes you have to be a little more careful under mod_perl, especially using
Registry, because of the persistence & subroutine-wrapping issues. But try
this [simplified] version of one of your examples:
my $i=0;
dosomefunnierstuff($i);
sub dosomefunnierstuff {
print "Funnierstuff is ", $_[0]++, "\n";
}
Most good coders would argue that functions that access variables that
aren't explicitly passed to them are best avoided anyway. This is just
another reason that's true (or another version of the same reasons).
Of course, since the strange behavior you observed is fully expected
once you understand the problem, slick (and disliked =) coders can feel
free to take advantage of it for their own evil purposes.
------------------- -------------------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED] The Math Forum
