On Tue, 2004-01-20 at 16:17, Stas Bekman wrote:
I now more or less have an idea on how to solve the code usage problem.
Great!
My idea is replace UNIVERSAL::AUTOLOAD with AUTOLOAD for each class that contains objects, so when the method is called on that object it'll do just that:
http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#C_AUTOLOAD_
ModPerl::MethodLookup::lookup_method is smart enough to figure out that if there are 3 modules that contain method read() and the object is blessed into Apache::RequestRec it'll load Apache::RequestIO and not the other 2 modules (APR::Bucket and Apache::Filter).
So essentially when mod_perl boots it will load a helper module ModPerl::EasyLife containing:
package ModPerl::EasyLife;
use ModPerl::MethodLookup;
sub my_AUTOLOAD {
my($hint, @modules) =
ModPerl::MethodLookup::lookup_method($UNIVERSAL::AUTOLOAD, @_);
if (@modules) {
eval "require $_" for @modules;
goto &$AUTOLOAD;
}
else {
die $hint;
}
}
*Apache::RequestRec::AUTOLOAD = *my_AUTOLOAD;
*Apache::ServerRec::AUTOLOAD = *my_AUTOLOAD;
*Apache::Filter::AUTOLOAD = *my_AUTOLOAD;
etc... for each class that contains object methodsin fact it'll automatically figure out the list of modules it needs to install AUTOLOAD for via the same old ModPerl::MethodLookup, and not hardcoded like in the above example.
So there will be no run-time overhead to figure out whether we have already installed AUTOLOAD or not, they will be installed by definition.
Also there should be an option to disable AUTOLOADing. This is for CPAN authors who will need to figure out which modules to load, to give their users the best performance in terms of better memory sharing.
What I don't have clear yet is the docs issue. Certainly you want to find the method of class Apache::RequestRec in its the right manpage (Apache::RequestRec). But $r has about 150 methods.
Yes, this is a trickier question. Looking at other big projects, it seems like DBI and CGI have chosen the "one huge page" approach. This still works fairly well since they make careful use of headings in the POD. Ideally, I'd certainly like to see all of the methods available through $r documented in Apache::RequestRec, even if it does make the page big. Any idea if it would be bigger than DBI or not?
I don't know. There are about 150 methods and the moment there are only skeletons for most. Once you fill them in with more text and examples it'll be enourmous. Just the TOC is going to be huge. Or it might just work.
If we eliminate the other manpages, I guess people can still use ModPerl::MethodLookup to find out whether they need to preload Apache::RequestIO, etc. Or we could mention for each method entry which physical .so object it lives in.
So my idea was to list all Apache::RequestRec methods in the Apache::RequestRec manpage, but have the bodies of most of them spread across Apache::RequestIO, etc, just like it is now. That's if you use the web interface. It won't quite work for 'perldoc'.
That would be my second choice if the one page is unmanageable. Which part doesn't work with perldoc? Just the actual links?
Yup, xrefs to other manpages.
__________________________________________________________________ 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]
