Nathan Byrd wrote:
[...]
Sorry for taking so long to get back with you.  I've finally gotten a
chance to start looking at this again.  Making the module changes with
hashes does seem to simplify things.  As to performance - besides your
point above about most of the work happening in the scripts, I believe
that this shouldn't be worse than mod_perl 1.x anyway since it is also
based on hash objects.  I suppose most people probably avoid PerlRun or
Registry as well if optimization is that important to them that they
would actually care about the performance difference between an array
based object and hash based object.

Also, I followed your suggestion and skipped making accessors for each
member.  When I started implementing them it seemed a little excessive
when using a hash based object.

Below is patches to RegistryCooker and RegistryLoader to use hash based
objects.  The following is a patched and tested (passes make test)
against the latest CVS. Please let me know what you think.

This patch does nothing, but replaced array based object with hash based one, right? that's fine with me. Thank you.


re: No accessors provided. So if tomorrow I fancy to change some key names, I can't do that since it'll break sub-classes, right? What if we need to add a new key? this may clobber the sub-classes private keys? If so, at least I'd suggest the subclasses to take safety precautions and name their keys as whatever_unique_string_ + attribute, e.g. par_foo, par_bar?

__________________________________________________________________
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


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to