Elizabeth Mattijsen wrote:
At 10:07 -0500 1/17/04, Geoffrey Young wrote:

> I realize (now) that there is a way to find out which method
> resides in which module:
http://perl.apache.org/docs/2.0/user/porting/porting.html#Using_C_ModPerl__MethodLookup__to_Discover_Which_mod_perl_2_0_Modules_Need_to_Be_Loaded


> but why does this have to be done manually? Why can't there be an

AUTOLOAD sub that _by default_ puts a warning in the error log, loads

> the right module and just makes the right sub gets called?
IIRC MethodLookup does have a 'load all' feature. but other than that, see
Apache::porting.

And it's not on by default, because AUTOLOAD introduces all kind of problems. And as explained in:
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#C_AUTOLOAD_
and I weren't able to use it in any phase before PerlChildInitHandler, which means that it won't work for your startup.pl.


The problem comes from the fact that we need to use UNIVERSAL::AUTOLOAD. We can't use plain package AUTOLOAD, precisely because of the chicken and egg problem. We don't know which module to load, and if we load them all, we don't need AUTOLOAD. So I figured UNIVERSAL::AUTOLOAD is the only workable solution.

If you have better ideas solving this problem I'm all ears.

That's fine, but that's introducing bloat (which may not be such a problem with perfork MPM's, but _may_ be a problem with other MPM's, particularly based on Perl 5 ithreads).

Maybe it shouldn't be an AUTOLOAD, but a custom die() handler... ;-)

But someone needs to trigger that custom die() handler. Or are you talking about installing $SIG{__DIE__} instead of using AUTOLOAD for trapping? You are aware that doing that comes with its own pile of problems, in certain contexts (.e.g. eval {} blocks)


Anyway, loading these methods on demand may actually be very useful for Perl 5 ithreaded based MPM's!

;)


__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to