In the end, this is just a style issue, as surely subroutines can be declared elsewhere. I would prefer to have my subroutines in the script in this particular instance because ... well, that's where they belong. This script is the only one using them, and the subroutines reference global variables declared and used in this script. No big deal, but I thought I'd give it a shot.
I'd come up with the code ref solution as well, but again, I'm trying to solve a style issue, and that's kinda ugly too. Thanks for replying though, I now know my options, and have "closure" on the issue - pun intended.
One thing I might suggest, if it seems worthy, is to add a config option to control the script caching behavior so that people aware of the closure issues can use embedded subs more freely; but that's about all I can think of.
This is interesting, but possibly unavoidable. If there is a good reason to
create a fix for this, perhaps we can find one. Like the prior post said, its
bad form to have subs in the script, and causes no end of problems.
To work around the closure issue that was catching a lot of people, recent
releases of Apache::ASP do not cache a script compilation that has a subroutine
defined in it, so the script is recompiled each time. Now it seems that you are
calling a routine, which calls itself and Apache::ASP tries to undefine the
existing subroutine with another compilation, and of course this does not work
since the subroutine is actively executing. Perhaps this is a "feature"
because having the subs in the script itself could result in a closure/sticky
variable again when it tries to execute itself if it were still compiled and we
cached the compilation.
My advice is if you really need to have subs in your script, then define it as a
code ref like so:
my $foo = sub {}; &$foo;
this will not have closure problems since you are executing it per request, and
it will therefore do the right thing, as well as allow recursive calling of the
script. Better yet if the subs can be moved to the global.asa or perl module.
Regards,
Josh
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
