Geoffrey Young wrote:

I should have noticed this before, but all the mod_perl foo in TestConfig really belongs in TestConfigPerl (including the stuff that was there before this flurry of commits :)

it's too late for 1.05 at this point (which I hope to release on monday or tuesday) but right afterward I'm going to clean up a bit and remove all traces of mod_perl from TestConfig.



Why? This code was there all the time and it has nothing to do with mod_perl and needed for any other perl project. Your quite shows like it wasn't added, but it wasn't, you have removed the - lines, which have shown where it existed before.


I'm not arguing about whether it was there before and you were just following suit. this isn't necessarily about the changes you just made.

ok

what I'm saying is that we have the TestConfigPerl class for configuring mod_perl specific widgets and TestConfig should probably be as non-httpd-core-module neutral as we can make it.
>
so, stuff like IS_MOD_PERL_2, IS_MOD_PERL_2_BUILD, and PerlRequire shouldn't be there conceptually. it just makes it harder to extend and maintain when there isn't a nice separation :)

Sure, so instead of:

  if (IS_MOD_PERL_2_BUILD || $ENV{APACHE_TEST_LIVE_DEV}) {

it should then say:

  if ($self->should_include_live_dev) {

which can be subclassed in TestConfigPerl with IS_MOD_PERL_2_BUILD moving there. so the superclass (TestConfig) goes:

  sub should_include_live_dev { return $ENV{APACHE_TEST_LIVE_DEV} ? 1 : 0 }

and TestConfigPerl:

   sub should_include_live_dev {
      return IS_MOD_PERL_2_BUILD || shift->SUPER::should_include_live_dev;
   }

does this sound reasonable?

__________________________________________________________________
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



Reply via email to