Nathan Byrd wrote:
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.)
[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.
When I was converting Apache::PAR to work with mod_perl 2.x, one problem
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.
If 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.
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 BekmanJAm_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
