[...]
That's not a problem. let's first figure out what's the best approach to take, before wasting time on fixing the style.The patch needs some minor tweaking to conform with our coding style, but overall it looks good. Though before we move on with this, won't it be simpler to use the 'fields' pragma?
Sorry about that - I'll take another look at the mod_perl coding guidelines before submitting another patch.
A good design philosophy is when the parent class can change its internal object implementation without affecting its sub-classes ;) I simply didn't think of sub-classes wanting to extend the object itself, but only to override some methods.Using fields would definitely be a good way of going about it. I didn't choose that approach in the code I submitted because: 1) I felt that implementing RegistryCooker as an array based object was a good design philosophy, and my changes (hopefully) shouldn't have much of an impact on the current working of the module unless its used in a subclass (and we have a win in that situation.)
2) Anything that looks like pseudo-hashes scares me. :-) Pseudo-hashes seem to be in flux, and as a result I went with the more "old fashioned" approach.
Yes, pseudo-hashes are out of question.
But this introduces a custom non-standard extending technique, which should rather stay away from if we can.I can also see it either way though: 1) It would be less code to implement this change as a fields pragma. 2) The fields pragma is promised to work as advertised even when the current pseudo-hash implementation goes away (as per the perlref doco.) I think overall I currently feel more comfortable with the array based patch mostly because even though its more lines, it seems to remain more familiarity to the original code. Also I felt that any performance or integration testing that has already been done with Registry scripts may be slightly invalidated with a change to the implementation structure of the module.
The test suite is covering enough to safely verify any refactorings, so I'm not worried about completely changing the internal object implementation. And no performance benchmarking was done so far.
It'd be nice to keep the extension mechanism as simple as possible, as long as we don't lose in performance. The fields manpage says that the fields are compiled, so perhaps using those will give us the same performance (or equal enough) compared with array-based objects. Is there some document that compares these two? I'm sure Damian's book talks about them all, but I'm not sure if there is a performance comparison there.While I was researching your question I mostly coded a solution to make this change with the fields pragma, just haven't tested it yet. If you want, I can also post that version to compare the current proposed patch with.
__________________________________________________________________
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]
