But I've noticed that Class::Std doesn't work very well with mod_perl due to the BEGIN{} block it depends on.

Actually it is a CHECK block that is the problem. Because of the way that mod_perl loads code, it does this after the CHECK and INIT phases of the perl compiler have run. This is the code which causes the issue (about line 258 in the lastest version on CPAN):

{
    no warnings qw( void );
    CHECK { initialize() }
}
[download]

Class::Std::initialize();   # Ensure run-time (and mod_perl) setup is 
+done
[download]

(1) - I stress should, because I am not TheDamian, and while I have read over the Class::Std code, I do not profess to understand all it's funky corners and details. However, logic and common sense dictate that if the CHECK block is not run, then just running the same code from the CHECK block should just work. But then again, this is TheDamian we are talking about ;)

Oooh. Thank you. That does indeed look mighty promising. This should probably work (once I upgrade my local Class::Std that is).

Thanks a bunch.

Let me suggest you try Object::InsideOut or Class::InsideOut instead of Class::Std. See Slides from NY Inside-Out Talk for reasons why.

I suggest you /msg [id://TheDamian] and ask him, since he's the most likely person to know the answer to your question.

"Class::Std::initialize()"
   This subroutine sets up all the infrastructure to support your
   Class::Std- based class. It is usually called automatically in a
   "CHECK" block, or (if the "CHECK" block fails to run -- under
   "mod_perl" or "require Class::Std" or "eval "..."") during the
   first constructor call made to a Class::Std-based object.

   In rare circumstances, you may need to call this subroutine
   directly yourself.  Specifically, if you set up cumulative,
   restricted, private, or automethodical class methods (see below),
   and call any of them before you create any objects, then you need
   to call "Class::Std::initialize()" first.
[download]

Damian