Re: [mp2] killing the ghost Apache:: usage?
At 18:28 -0800 1/16/04, Stas Bekman wrote: Geoffrey Young wrote: 2) liz, your opinion here is especially valuable wrt what is "intuitive." stas and I both have our own (generally differing) opinion of API intuitiveness, and as someone who is in the middle of figuring out the new API, you represent a good test case. of course, if we don't agree with your opinion, well... ;) May be we should open up this question for more people? Please do. I don't think I can qualify as a "user" in that respect. Yes, I have used mod_perl from almost the very beginning, but there has been a "hole" in my experience from say 1999 through 2002... There are quite a few folks who have moved to mp2 or in the process of doing so and certainly will have things to say. I'd suggest to ask for their input of what people have found hard and whether we need to change things before 2.0 is cast in stone. Certainly we aren't oblidged to follow all the suggestions, but it's a good idea to hear what users have to say. What I really find annoying, is that when you're porting, things start to fail. 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? Liz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] killing the ghost Apache:: usage?
> What I really find annoying, is that when you're porting, things start > to fail. agreed. that's even the basis for the mp2 talk I've been giving and the article I wrote for perl.com - porting is lots more frustrating than we sometimes make it out to be. > 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. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] killing the ghost Apache:: usage?
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. 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... ;-) Anyway, loading these methods on demand may actually be very useful for Perl 5 ithreaded based MPM's! Liz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] killing the ghost Apache:: usage?
>> > 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. > > > 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). of course. they are just meant to get you past the porting hurdle. > > Maybe it shouldn't be an AUTOLOAD, but a custom die() handler... ;-) Apache::porting is close to this I think. I haven't used it, but that's how stas has described it. > > Anyway, loading these methods on demand may actually be very useful for > Perl 5 ithreaded based MPM's! :) --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] killing the ghost Apache:: usage?
Hi, Am Donnerstag, 15. Januar 2004 01:41 schrieb Stas Bekman: > Please take a look at this new manpage > http://perl.apache.org/docs/2.0/api/Apache.html > > This issue of ghost Apache namespace troubles me. In mod_perl 1.0 it was OK > to have functions like Apache::current_callback() because almost everything > was preloaded. I don't think it's OK in mp2. It's absolutely not obvious > which module needs to be loaded to get this API, and most people will try > to load Apache, and it won't do the trick. > This is very confusing and incomprehencible to me. My last mp2 application starts with: use mod_perl 1.99; use Apache::RequestRec (); use Apache::RequestIO (); use Apache::ServerUtil (); use Apache::RequestUtil (); use Apache::Util (); use APR::Date (); use APR::Table(); and im sure my next project start with this lines too. If someone ask why my answer is I do not know, but it does not work otherwise. perldoc does not know anything of the above. On startup, my handler get a RequestRec object, but to use parts of it I have to load another module 'Apache::RequestIO'. This powers my requestrec up, but why and how??? RequestIO is not inhereted from RequestRec. Also I have not created a object of type RequestIO they are just unrelated to eachother. I whould expect a full working object from the beginning. If my program does more than passing a obj ref around the I know I have to load this object's module. use Apache::RequestRec nothing more. This is the same for all other Apache::* modules, please do not populate others namespace without reason. Nor bother a user to load a module he did not use. > Why not replace: > >use ModPerl::Util; >my $callback = Apache::current_callback(); > > with: > >use ModPerl::Util; >my $callback = ModPerl::Util::current_callback(); please do so > then: > >use Apache::ServerUtil; >my $server_root = Apache::server_root; > > with: > >use Apache::ServerUtil; >my $server_root = Apache::ServerUtil::server_root; this is what I whould expect. > > etc. (there are many modules which install things into the Apache:: > namespace). i.e. try to use the same namespace as the module the function > lives in. > > The only obvious need-to-keep is Apache->server, which can really be made a > constant too. > > or do you think it's OK the way things are right now? The manpage suggests no, please not. > to use http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html to > figure what needs to be loaded, but it's not so intuitive. > > The only real problem with this change suggestion is backwards > compatibility, which is nice to keep small. I think backwards compatibility is not of interest here, mod_perl2 is not released and nearly everything has a new name rightnow. The number of users that have really production mp2 applications is small and the one that runs a old source with Apache::compat can do so, he did not notice the changes anyway. > > > __ > Stas BekmanJAm_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] -- Boris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] killing the ghost Apache:: usage?
Hi, Am Samstag, 17. Januar 2004 16:16 schrieb Elizabeth Mattijsen: [...] > Anyway, loading these methods on demand may actually be very useful > for Perl 5 ithreaded based MPM's! > but for forkbased servers it is just the opposite. I dislike your AUTOLOAD idea for that reason. > > Liz -- Boris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] killing the ghost Apache:: usage?
Boris Zentner wrote: RequestIO is not inhereted from RequestRec. Also I have not created a object of type RequestIO they are just unrelated to eachother. I whould expect a full working object from the beginning. If my program does more than passing a obj ref around the I know I have to load this object's module. use Apache::RequestRec nothing more. This is the same for all other Apache::* modules, please do not populate others namespace without reason. Nor bother a user to load a module he did not use. For the record, I agree with Boris on this. Users should never be required to use methods defined in namespaces of modules that they did not explicitly load, and modules should not define things in other namespaces (like the Apache:: stuff that started this thread). I don't have any production mp2 code, so I'm probably less worried about backwards compatibility than some people, but I think you could handle the issue with some alias methods that print a warning about being deprecated and then call the new method names. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] killing the ghost Apache:: usage?
> For the record, I agree with Boris on this. Users should never be > required to use methods defined in namespaces of modules that they did > not explicitly load, and modules should not define things in other > namespaces (like the Apache:: stuff that started this thread). well, there are a few reasons for all of this. granted, it doesn't really make sense before you, well, understand it, but I like it :) so, here's my view on the whole thing... take Apache::RequestRec. it implements methods that provde access to the apache request_rec structure. so, load it and you get access to things like $r->uri() and $r->notes(), which are stored as the uri and notes slots in the C request_rec. now, take a method like is_initial_req(), which represents access to ap_is_initial_req. the call only makes sense at request-time, and the Apache API requires a request_rec structure. but it doesn't make sense to define it in Apache::RequestRec, since it does not access a property of the request_rec structure. so, it's definition is elsewhere, in Apache::RequestUtil, but Apache::RequestUtil defines Apache::RequestRec::is_initial_req(). the end result is that you can have the Perlish $r->is_initial_req() instead of the bulky Apache::RequestUtil::is_initial_req($r). basically, in Perl we get an API that makes sense: operations that require a request_rec in C are called from $r in Perl. why not just define is_initial_req() in Apache::RequestRec? well, for one it makes for a cleaner design: each of request_rec, server_rec, connection_rec have their own classes that provide access only to the slots in their specific record. but another good thing is that if your application only needs access to notes() and other request_rec attributes, then your code profile isn't bloated with symbols for is_initial_req() and other non-request_rec methods. while this may feel new, it's actually not: in mp1 you couldn't call $r->log->info without first loading Apache::Log, nor could you call $r->meets_conditions without first loading Apache::File. I suspect (but don't know for certain) that this was an implementation style that popped up later in mp1's lifecycle, and that Doug decided it was the way mp2 ought to work. personally, I'm really in favor of the way things look now (save the things that started this thread). not only do they represent a cleaner Perl API layer (my favorite part) but they allow applications to keep unnecessary symbols out of their code. granted, it takes a while to get used to, but I like it and I hope it will grow on everyone as it has on me. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] killing the ghost Apache:: usage?
At 18:02 +0100 1/17/04, Boris Zentner wrote: Am Samstag, 17. Januar 2004 16:16 schrieb Elizabeth Mattijsen: [...] Anyway, loading these methods on demand may actually be very useful > for Perl 5 ithreaded based MPM's! but for forkbased servers it is just the opposite. I dislike your AUTOLOAD idea for that reason. Exactly for that reason I once developed the "load.pm" module on CPAN. In prefork MPM's it would automatically load all of the subs, in other environmens it would load on demand. Maybe something similar could be done here? Liz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] killing the ghost Apache:: usage?
Boris Zentner wrote: Anyway, loading these methods on demand may actually be very useful for Perl 5 ithreaded based MPM's! but for forkbased servers it is just the opposite. I dislike your AUTOLOAD idea for that reason. It's not quite opposite. You don't want to load 40+ modules if you are going to use only 3 of them. It's out of question that we are going to preload them by default. You are probably unaware that there are that many modules in mp2. If you really want to there is ModPerl::MethodLookup::preload_all_modules(), but please keep it in your config and don't put it in any CPAN modules: http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#C_preload_all_modules___ __ Stas BekmanJAm_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]
Re: [mp2] killing the ghost Apache:: usage?
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 BekmanJAm_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]
Re: [mp2] killing the ghost Apache:: usage?
Geoffrey Young wrote: For the record, I agree with Boris on this. Users should never be required to use methods defined in namespaces of modules that they did not explicitly load, and modules should not define things in other namespaces (like the Apache:: stuff that started this thread). well, there are a few reasons for all of this. granted, it doesn't really make sense before you, well, understand it, but I like it :) so, here's my view on the whole thing... [snipped the explanation of why being able to load each module separately is a goodness ] Josh Chamas has suggested some time ago to have a package which will preload groups of modules. So if you don't care about fine tuned performance you could say: use Apache::whatever qw(:request :server); and it'll load Apache::Request* and Apache::Server*. We can define more groups. Still some of these methods return objects which require other packages to be loaded. So dir_config requires APR::Table to be loaded, etc. So I'm not sure how much win this is going to make. And again, we won't want this Apache::whatever module to be used in CPAN modules, and rather have the authors load explicitly only the modules that really need to. __ Stas BekmanJAm_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]
Re: [mp2] killing the ghost Apache:: usage?
Boris Zentner wrote: Hi, Am Donnerstag, 15. Januar 2004 01:41 schrieb Stas Bekman: Please take a look at this new manpage http://perl.apache.org/docs/2.0/api/Apache.html This issue of ghost Apache namespace troubles me. In mod_perl 1.0 it was OK to have functions like Apache::current_callback() because almost everything was preloaded. I don't think it's OK in mp2. It's absolutely not obvious which module needs to be loaded to get this API, and most people will try to load Apache, and it won't do the trick. This is very confusing and incomprehencible to me. My last mp2 application starts with: use mod_perl 1.99; use Apache::RequestRec (); use Apache::RequestIO (); use Apache::ServerUtil (); use Apache::RequestUtil (); use Apache::Util (); use APR::Date (); use APR::Table(); and im sure my next project start with this lines too. If someone ask why my answer is I do not know, but it does not work otherwise. And that's fine. Think of mp2 as a bunch of CPAN modules. You need to load them before you can use them. I guess people will appreaciate this separation once they will run mp2 in production. mp2 comes with more than 40 modules and more than 400 methods. Compared to 3 modules in mp1 (which you still had to load, remember!) and some 100 methods. If mp2 did what mp1 did you will get too much unnecessary bloat. perldoc does not know anything of the above. because of the Apache2 issue. You need to use mp2doc (and it needs to be documented) or patch perldoc to load 'use Apache2'. __ Stas BekmanJAm_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]
Re: [mp2] killing the ghost Apache:: usage?
Geoffrey Young wrote:
it's definition is elsewhere, in
Apache::RequestUtil, but Apache::RequestUtil defines
Apache::RequestRec::is_initial_req(). the end result is that you can have
the Perlish $r->is_initial_req() instead of the bulky
Apache::RequestUtil::is_initial_req($r).
I would much prefer the longer one. It's more typing, but it also is
much clearer. The current behavior just looks wrong to me.
Alternatively, you could be sneaky about it and load on demand, hiding
this class completely from end users. Here's a simple exampe with no
AUTOLOAD evil:
sub is_initial_req {
my $self = shift;
require Apache::RequestUtil;
return Apache::RequestUtil::is_initial_req($self);
}
People who want to call the sub (shouldn't it actually be a method?)
directly for speed still can.
why not just define is_initial_req() in Apache::RequestRec? well, for one
it makes for a cleaner design: each of request_rec, server_rec,
connection_rec have their own classes that provide access only to the slots
in their specific record. but another good thing is that if your
application only needs access to notes() and other request_rec attributes,
then your code profile isn't bloated with symbols for is_initial_req() and
other non-request_rec methods.
I think my approach above handles both of those. People who want to
preload can look at what's in %INC after running their app.
while this may feel new, it's actually not: in mp1 you couldn't call
$r->log->info without first loading Apache::Log, nor could you call
$r->meets_conditions without first loading Apache::File.
But I didn't care then because those were obscure functions that I never
used...
- Perrin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] killing the ghost Apache:: usage?
Hi, Am Sonntag, 18. Januar 2004 01:13 schrieb Stas Bekman: > Boris Zentner wrote: > >>Anyway, loading these methods on demand may actually be very useful > >>for Perl 5 ithreaded based MPM's! > > > > but for forkbased servers it is just the opposite. I dislike your > > AUTOLOAD idea for that reason. > > It's not quite opposite. You don't want to load 40+ modules if you are > going to use only 3 of them. It's out of question that we are going to > preload them by default. You are probably unaware that there are that many > modules in mp2. > I do not want to preload all modules, I like to preload my modules, and only the ones I need before apache forks. Just to share them at least at this point. With the autoload aproach all my server load the missing functions after each other and need x times more mem. Sorry if this was not so clear. > If you really want to there is > ModPerl::MethodLookup::preload_all_modules(), but please keep it in your > config and don't put it in any CPAN modules: > http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#C_preload_all >_modules___ > > > __ > Stas BekmanJAm_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] -- Boris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] killing the ghost Apache:: usage?
Perrin Harkins wrote:
Geoffrey Young wrote:
it's definition is elsewhere, in
Apache::RequestUtil, but Apache::RequestUtil defines
Apache::RequestRec::is_initial_req(). the end result is that you can
have
the Perlish $r->is_initial_req() instead of the bulky
Apache::RequestUtil::is_initial_req($r).
I would much prefer the longer one. It's more typing, but it also is
much clearer. The current behavior just looks wrong to me.
But Apache::RequestUtil::is_initial_req($r) is wrong. Because it a method and
not a function. It makes it impossible to subclass it.
That's just silly. Most people will need to load: Apache::Request(Rec|IO|Util)
and may be Apache::Server(Util)? I see no legitimate reason to make things
obscure.
Alternatively, you could be sneaky about it and load on demand, hiding
this class completely from end users. Here's a simple exampe with no
AUTOLOAD evil:
sub is_initial_req {
my $self = shift;
require Apache::RequestUtil;
return Apache::RequestUtil::is_initial_req($self);
}
yuck, that's so inefficient.
__
Stas BekmanJAm_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]
Re: [mp2] killing the ghost Apache:: usage?
Boris Zentner wrote: Hi, Am Sonntag, 18. Januar 2004 01:13 schrieb Stas Bekman: Boris Zentner wrote: Anyway, loading these methods on demand may actually be very useful for Perl 5 ithreaded based MPM's! but for forkbased servers it is just the opposite. I dislike your AUTOLOAD idea for that reason. It's not quite opposite. You don't want to load 40+ modules if you are going to use only 3 of them. It's out of question that we are going to preload them by default. You are probably unaware that there are that many modules in mp2. I do not want to preload all modules, I like to preload my modules, and only the ones I need before apache forks. Just to share them at least at this point. With the autoload aproach all my server load the missing functions after each other and need x times more mem. Sorry if this was not so clear. In which case it seems that you are saying exactly what Liz does: i.e. you want to be able to load only the modules that you are going to use. Nobody is forcing you to use AUTOLOAD if you don't want to. Or may be I've lost you and not quite following what your point/disagreement is. __ Stas BekmanJAm_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]
Re: [mp2] killing the ghost Apache:: usage?
Hi, Am Sonntag, 18. Januar 2004 01:32 schrieb Stas Bekman: > Boris Zentner wrote: > > Hi, > > > > Am Donnerstag, 15. Januar 2004 01:41 schrieb Stas Bekman: > >>Please take a look at this new manpage > >>http://perl.apache.org/docs/2.0/api/Apache.html > >> > >>This issue of ghost Apache namespace troubles me. In mod_perl 1.0 it was > >> OK to have functions like Apache::current_callback() because almost > >> everything was preloaded. I don't think it's OK in mp2. It's absolutely > >> not obvious which module needs to be loaded to get this API, and most > >> people will try to load Apache, and it won't do the trick. > > > > This is very confusing and incomprehencible to me. My last mp2 > > application starts with: > > > > use mod_perl 1.99; > > use Apache::RequestRec (); > > use Apache::RequestIO (); > > use Apache::ServerUtil (); > > use Apache::RequestUtil (); > > use Apache::Util (); > > use APR::Date (); > > use APR::Table(); > > > > and im sure my next project start with this lines too. If someone ask why > > my answer is I do not know, but it does not work otherwise. > > And that's fine. Think of mp2 as a bunch of CPAN modules. You need to load > them before you can use them. That is fine and reasonable to me. My point is that once I have an object I want to be sure that I can use every method for this object. For example this implies that whenever I have a RequestRec object that can print, I must be sure that I can do so without loading Apache::RequestIO. It is ok to 'use APR::Date' if I like to use a function of it or operate on a object that I can produce. But it is not ok in my opinion that my Apache::RequestRec object gets magical date methods. > > I guess people will appreaciate this separation once they will run mp2 in > production. mp2 comes with more than 40 modules and more than 400 methods. > Compared to 3 modules in mp1 (which you still had to load, remember!) and > some 100 methods. If mp2 did what mp1 did you will get too much unnecessary > bloat. > > > perldoc does not know anything of the above. > > because of the Apache2 issue. You need to use mp2doc (and it needs to be > documented) or patch perldoc to load 'use Apache2'. > > __ > Stas BekmanJAm_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] -- Boris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] killing the ghost Apache:: usage?
Am Sonntag, 18. Januar 2004 06:35 schrieb Stas Bekman: > Boris Zentner wrote: > > Hi, > > > > Am Sonntag, 18. Januar 2004 01:13 schrieb Stas Bekman: > >>Boris Zentner wrote: > Anyway, loading these methods on demand may actually be very useful > for Perl 5 ithreaded based MPM's! > >>> > >>>but for forkbased servers it is just the opposite. I dislike your > >>>AUTOLOAD idea for that reason. > >> > >>It's not quite opposite. You don't want to load 40+ modules if you are > >>going to use only 3 of them. It's out of question that we are going to > >>preload them by default. You are probably unaware that there are that > >> many modules in mp2. > > > > I do not want to preload all modules, I like to preload my modules, and > > only the ones I need before apache forks. Just to share them at least at > > this point. > > > > With the autoload aproach all my server load the missing functions after > > each other and need x times more mem. > > > > Sorry if this was not so clear. > > In which case it seems that you are saying exactly what Liz does: i.e. you > want to be able to load only the modules that you are going to use. Nobody > is forcing you to use AUTOLOAD if you don't want to. Or may be I've lost > you and not quite following what your point/disagreement is. This is what happened so far ( or what I read so far ): Liz: suggested if a method is not found we can use autoload to load with a warning. That is better as error. AND this aproach is a good one, if you use a ithread using server. Boris: Yes this is nice, but if someone use a forked server it whould be far better not to load all this functions on demand because it use so much more mem. I agree with liz. But for my kind of server this is not the all time best, it is better as before ;-) > > __ > Stas BekmanJAm_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 -- Boris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] killing the ghost Apache:: usage?
Boris Zentner wrote: [...] In which case it seems that you are saying exactly what Liz does: i.e. you want to be able to load only the modules that you are going to use. Nobody is forcing you to use AUTOLOAD if you don't want to. Or may be I've lost you and not quite following what your point/disagreement is. This is what happened so far ( or what I read so far ): Liz: suggested if a method is not found we can use autoload to load with a warning. That is better as error. AND this aproach is a good one, if you use a ithread using server. Boris: Yes this is nice, but if someone use a forked server it whould be far better not to load all this functions on demand because it use so much more mem. I agree with liz. But for my kind of server this is not the all time best, it is better as before ;-) It's clear now, Boris. I thought you were arguing for preloading all modules before. Don't worry, we won't use AUTOLOAD, since as I've explained it doesn't quite work everywhere (because it's not AUTOLOAD but UNIVERSAL::AUTOLOAD). __ Stas BekmanJAm_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]
Re: [mp2] killing the ghost Apache:: usage?
Stas Bekman wrote:
Perrin Harkins wrote:
Geoffrey Young wrote:
it's definition is elsewhere, in
Apache::RequestUtil, but Apache::RequestUtil defines
Apache::RequestRec::is_initial_req(). the end result is that you can
have
the Perlish $r->is_initial_req() instead of the bulky
Apache::RequestUtil::is_initial_req($r).
I would much prefer the longer one. It's more typing, but it also is
much clearer. The current behavior just looks wrong to me.
But Apache::RequestUtil::is_initial_req($r) is wrong. Because it a
method and not a function. It makes it impossible to subclass it.
I was just following what Geoff said. The example still works if you
make it Apache::RequestUtil->is_initial_req($r) instead.
That's just silly. Most people will need to load:
Apache::Request(Rec|IO|Util) and may be Apache::Server(Util)? I see no
legitimate reason to make things obscure.
I'm not sure what you mean. Don't you think it's more obscure to
require people to load class Foo in order to make a method in class Bar
available? If they already have to explicitly load those modules, I
can't see why calling methods in those modules would be more confusing.
Alternatively, you could provide arguments to import which would load
support modules behind the scenes:
use Apache::RequestRec qw(:io :util);
I'm not crazy about that idea though, since it's a confusing use of import.
Alternatively, you could be sneaky about it and load on demand, hiding
this class completely from end users. Here's a simple exampe with no
AUTOLOAD evil:
sub is_initial_req {
my $self = shift;
require Apache::RequestUtil;
return Apache::RequestUtil::is_initial_req($self);
}
yuck, that's so inefficient.
It adds a hash lookup and one method call, and it would only exist for
people who want to be able to say $r->is_initial_req(). People who are
worried about efficiency would call
Apache::RequestRecUtil->is_initial_req($r) instead.
- Perrin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] killing the ghost Apache:: usage?
Boris Zentner wrote: Hi, Am Sonntag, 18. Januar 2004 01:32 schrieb Stas Bekman: Boris Zentner wrote: Hi, Am Donnerstag, 15. Januar 2004 01:41 schrieb Stas Bekman: Please take a look at this new manpage http://perl.apache.org/docs/2.0/api/Apache.html This issue of ghost Apache namespace troubles me. In mod_perl 1.0 it was OK to have functions like Apache::current_callback() because almost everything was preloaded. I don't think it's OK in mp2. It's absolutely not obvious which module needs to be loaded to get this API, and most people will try to load Apache, and it won't do the trick. This is very confusing and incomprehencible to me. My last mp2 application starts with: use mod_perl 1.99; use Apache::RequestRec (); use Apache::RequestIO (); use Apache::ServerUtil (); use Apache::RequestUtil (); use Apache::Util (); use APR::Date (); use APR::Table(); and im sure my next project start with this lines too. If someone ask why my answer is I do not know, but it does not work otherwise. And that's fine. Think of mp2 as a bunch of CPAN modules. You need to load them before you can use them. That is fine and reasonable to me. My point is that once I have an object I want to be sure that I can use every method for this object. For example this implies that whenever I have a RequestRec object that can print, I must be sure that I can do so without loading Apache::RequestIO. It is ok to 'use APR::Date' if I like to use a function of it or operate on a object that I can produce. But it is not ok in my opinion that my Apache::RequestRec object gets magical date methods. But none of Apache::Request* classes is a subclass of each other. There is no inheritance tree. All they do is nicely spread the methods across several modules, giving you better fine tuning. So when you get $r in your handler we have no idea what methods you are going to need, and which classes you need to load. It's quite possible that you never going to use Apache::RequestRec, so any guessing is wrong. I think the best solution for your kind of pain is the one that Josh has proposed: use Apache::whatever qw(:request); and you get all Apache::Request* modules loaded and now you have all the mp2 methods that you can operate on $r. use Apache::whatever qw(:request :server); and you get Apache::Request* and Apache::Server* loaded. That is very similar to how CGI.pm imports its function interface symbols via tags, though here we deal with modules. __ Stas BekmanJAm_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]
Re: [mp2] killing the ghost Apache:: usage?
Perrin Harkins wrote:
Stas Bekman wrote:
Perrin Harkins wrote:
Geoffrey Young wrote:
it's definition is elsewhere, in
Apache::RequestUtil, but Apache::RequestUtil defines
Apache::RequestRec::is_initial_req(). the end result is that you
can have
the Perlish $r->is_initial_req() instead of the bulky
Apache::RequestUtil::is_initial_req($r).
I would much prefer the longer one. It's more typing, but it also is
much clearer. The current behavior just looks wrong to me.
But Apache::RequestUtil::is_initial_req($r) is wrong. Because it a
method and not a function. It makes it impossible to subclass it.
I was just following what Geoff said. The example still works if you
make it Apache::RequestUtil->is_initial_req($r) instead.
it's not the same. this call is:
Apache::RequestUtil::is_initial_req('Apache::RequestUtil', $r)
That's just silly. Most people will need to load:
Apache::Request(Rec|IO|Util) and may be Apache::Server(Util)? I see no
legitimate reason to make things obscure.
I'm not sure what you mean. Don't you think it's more obscure to
require people to load class Foo in order to make a method in class Bar
available? If they already have to explicitly load those modules, I
can't see why calling methods in those modules would be more confusing.
Heh, I guess we have lost the track of who wants what. I started this thread
exactly suggesting to eliminate this obscurity and not advocating for it.
Alternatively, you could provide arguments to import which would load
support modules behind the scenes:
use Apache::RequestRec qw(:io :util);
I'm not crazy about that idea though, since it's a confusing use of import.
that's what I've just suggested (Josh's idea). Though it's better be some
other common name which will handle any groups and not Apache::RequestRec,
because you don't necessarily need Apache::RequestRec at all.
Alternatively, you could be sneaky about it and load on demand,
hiding this class completely from end users. Here's a simple exampe
with no AUTOLOAD evil:
sub is_initial_req {
my $self = shift;
require Apache::RequestUtil;
return Apache::RequestUtil::is_initial_req($self);
}
yuck, that's so inefficient.
It adds a hash lookup and one method call, and it would only exist for
people who want to be able to say $r->is_initial_req(). People who are
worried about efficiency would call
Apache::RequestRecUtil->is_initial_req($r) instead.
to be efficient it needs to do: goto &$AUTOLOAD; after loading
Apache::RequestUtil, so it'll happen only once.
What if you don't load 'Apache::RequestRec'? Who is going to load that wrapper?
What if people do load Apache::RequestUtil:
$r->is_initial_req($self)
now you've sub redefined in either of the two modules.
__
Stas BekmanJAm_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]
