I think this would be very helpful for newbies. I think almost all of them will get stung otherwise and that could keep them from seeing how great Apache::ASP really is. I encountered the phenomenon early on (before I realized the style guide had been made available). It was pretty maddening for a couple of days, until I moved everything that was complex enough to have a subroutine into modules.
Of course, now that the style guide is available you could just say "read the guide," but many will probably try to dive in without reading it. If subroutines in scripts worked as expected, even if they were a little slow, it might prevent newbies from unfairly writing off Apache::ASP as buggy. Thanks for thinking about us newbies! Without newbies there would never be experts. -dave --- In [EMAIL PROTECTED], Josh Chamas <[EMAIL PROTECTED]> wrote: > Hi, > > I am interested in applying a fix to Apache::ASP that has some > significant implications and would like to put this out for comment. > > The problem is that when subroutines are defined in a script, > they create closure issues as discussed here: > > http://www.apache-asp.org/style.html#Do%20not%20definc430b103 > > The greater problem is that resolving these closure issues can > be a hair pulling event, and unless one gets into mod_perl > and Apache::ASP significantly, this may be overlooked. I would > like Apache::ASP to be more newbie friendly. > > The solution is whenever a subroutine definition is detected as in: > > sub some_name { > > } > > that script will be compiled as normal, but the (re)compilation > will be forced each script invocation. The closure issues will > go away because the subroutines will be redefined each script > request. The downside is that there will be a performance hit > where there was none before. > > Any advanced user should know not to put subs in scripts, > so I am not worried about the performance hit to people that > know what they are doing. This in effect would create a > penalty for those that do not follow the STYLE GUIDE. > > Because this fix will be functionally transparent, I do not > think I should save it for 3.0 > > There is another associated fix, to recompile global.asa per > request when XMLSubs are detected there, or subs defined > in a package not their own, as in: > > sub package::some_sub { > > } > > which can also create closure issues. I don't believe this is > as frequent a problem for newbies though, so not as concerned > about this and can save this fix for later sometime if necessary. > > Any comments? > > Thanks, > > Josh > > ________________________________________________________________ > Josh Chamas, Founder phone:925-552-0128 > Chamas Enterprises Inc. http://www.chamas.com > NodeWorks Link Checking http://www.nodeworks.com > > > -------------------------------------------------------------------- - > 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]