Doug MacEachern wrote:

On Sun, 16 Sep 2001, Stas wrote:


and what's the user of $class? When you can access it via __PACKAGE__ and you don't really need it anyway.


__PACKAGE__ is not helpful if one day a test .pm wants to inherit APACHE_TEST_CONFIGURE from another class. most of the Apache::Test* is OO, so i am thinking that way here.


But not the tests. How possibly can you use the inheritance of APACHE_TEST_CONFIGURE, when it's a true function that does a setup of something that's *always* being run before any tests are getting executed. If you inherit this function, you will run exactly the same code, because the API doesn't pass anything but the config object. but then you run this function anyway.

Please give me a single example where you may want to inherit from APACHE_TEST_CONFIGURE. I can hardly imagine which good use some other class may have from inheriting this function.


I think this is even better, as can is already returning a ref to a sub if found.

        if (my $cv = $module->can('APACHE_TEST_CONFIGURE')) {
            eval { $cv->($self) };
            warn $@ if $@;
        }


looks nicer yeah, but you shouldn't be looking up a method via @ISA if you won't be calling it as a method. (disclaimer: i think am guilty of having done that in the past though)


I think that $self->$cv is valid too, since you have a ref to the sub already. So here you get to call $cv as a method.


but i think the current way in cvs is correct.

true, it's correct. I just didn't want to add any data to the API, that
you will never use.



how do you know it will never be used? its much easier to pass along that little piece of data and let people ignore it than to try and retrofit something the day somebody says they do need it.

sure, I agree. I just thought that APACHE_TEST_* subs will be all functions and not OO methods, therefore I think that passing $module is just confusing.


But if you think it may be of use in the future, sure let's keep it that way.


_____________________________________________________________________ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/




Reply via email to