Nathan Byrd wrote:
[EMAIL PROTECTED] would be the right place. Also help with the doc would be *very* appreciated, I've started to write the initial doc, but it's a far away from being useful.All,To begin with, should proposed mod_perl patches go to [EMAIL PROTECTED]? The documentation seemed a little unclear in this case (I decided to play it safe since I didn't run across any messages on the dev list from outside developers.)
When I was converting Apache::PAR to work with mod_perl 2.x, one problemIf you want to extend the object itself, what we can do is to provide a class method which will return the current size of the object. I suggest a method, so sub-classes can be further sub-classable.
I had was with the way in which ModPerl::RegistryCooker stores member
data. Any subclass of ModPerl::RegistryCooker (in my case, for
Apache::PAR::RegistryCooker) that need to store their own module data
have a problem - they need to pick an array element to store their data
in. Because of the way in which ModPerl::RegistryCooker works
currently, that means hardcoding an array index (because not all array
members are created in new or init). Thus, in
Apache::PAR::RegistryCooker I have a line similar to the following:
use constant PARDATA => 8;
This is not optimal, especially since this has already changed in the
CVS version of RegistryCooker since I started working on it - luckily,
to less members, not more :-)
I propose a change to RegistryCooker.pm so that member data is always
defined in the init sub, so that I could change the above line to
something more like:
use constant PARDATA => -1;
and in my handler, push a new element on after new has been called. This would keep future changes to the RegistryCooker script from
potentially breaking other modules which must store their own data as
well.
Below is a (small) patch to the CVS version of RegistryCooker.pm to do
this. Down side is that if new member data is added, it would then also
need to be added to the init sub.
package A;
use constant SIZE => 5;
sub object_size { SIZE }
package B;
use constant EXTRA_SIZE => 2;
use base qw(A);
sub object_size { SUPER::object_size + EXTRA_SIZE);
package C;
use constant EXTRA_SIZE => 2;
use base qw(B);
sub object_size { SUPER::object_size + EXTRA_SIZE);
etc...
of course here we cast in stone the implementation of the object as an ARRAY, which is not so cool.
Alternatively we can provide a function to create accessor methods, which will transparently handle internal changes.
We could also use the 'fields' pragma, but than we get married to the hash internals, though apparently an optimized compiled time one. We need it working for 5.6.1+, is it working fine with 5.6.1?
Pseudohashes are certainly out of question.
__________________________________________________________________
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
