Boris Zentner wrote:
Hi,

Am Dienstag, 20. Januar 2004 19:51 schrieb Perrin Harkins:

What about the other 200+
methods in about 30 modules? People will still need to figure out what to
load to use these (e.g. Apache::URI's methods don't necessarily work with
$r, so how do you know that you need to load that module?)

I think it's fine for people to explicitly load Apache::URI in order to call methods like Apache::URI->foo(), but not for methods that are called through $r, or $s, or any other object that the user gets passed.


Where do you install that
AUTOLOAD on functions or modules which aren't $r or $s operators?

I don't want to AUTOLOAD anything that isn't called through one of those.


This is exactly what I try to say for the last x mails. Whenever I act with a object of type x, I do a 'use x;'. Here a example I can use print without RequestIO but sure I must load APR::Table to use method set.

use APR::Table;
use Apache::RequestRec;
sub handler : method {
  my $r = shift;
  $r->print('xx');
  my $t = $r->notes;
  $t->set('foo');
}

That's not what Perrin is talking about I think. So you do suggest that a user need to load 'Apache::RequestRec' to get $r methods?


Perrin suggests that you don't need to load anything from your code, because you already receive $r, so the methods should be there already. Compared to the situation where you create the object by yourself. So if I understand Perrin's vision, that code should work with:

use APR::Table;
sub handler : method {
  my $r = shift;
  $r->print('xx');
  my $t = $r->notes;
  $t->set('foo');
}

my problem is why $r is magical, but not $t. Why inconsistency? if you didn't create $t, you shouldn't need to load APR::Table, it should be there for you, just like with $r.

So as you can see your and Perrin's views aren't exactly the same. Please correct me if I'm wrong.

__________________________________________________________________
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