On Tue, 2003-02-11 at 18:10, Stas Bekman wrote:
> Are there any other folks out there that care about the implementation
> details? That's a pure Perl afterall. It'd be nice to hear more opinions.
>
[...]
> > I was referring to the fact that AFAIK the fields pragma is currently
> > (with 5.61 anyway, haven't checked with 5.8) implemented in terms of
> > pseudo-hashes. Not really important though since we don't have to mess
> > with them directly.
>
> That sucks then. e.g. Apache::Reload doesn't work with pseudo-hashes, but I'm
> not sure if this affects the fields pragma.
>
Yeah, not sure about that. I do know that its implemented with
pseudo-hashes with 5.6.1, if for no other reason than the error that I
was trying to resolve earlier was:
"No such pseudo-hash field "REQ" at " ...
[...]
> > On the other hand, with this extending technique we also gain the
> > flexibility of changing any of those accessors/mutators in the future to
> > do input parameter checking, side effects, etc. To do that we would just
> > make a accessor/mutator by hand. For example:
> > sub FILENAME {
> > my $self = shift;
> > my $val = undef;
> > if(@_) {
> > $val = $_[0];
> > ... code to check value, change $val, return, etc ...
> > $self->[_FILENAME] = $val;
> > }
> > return $self->[_FILENAME];
> > }
> > And rename the current FILENAME accessor/mutator in the call to public.
> > We could also decide later to make some of the members read only this
> > way, deprecate them using warnings, etc.
>
> Sounds good.
>
The problem with trying to do this with the fields pragma is that we
would still need to automatically create accessors/mutators if we want
to encapsulate this data to be able to do the above, and as such would
end up with an equivalent extending technique plus the changes for the
fields pragma, which is probably not what we want.
[...]
> > but its the only way I've found so far to support
> > both mod_perl 1.x Apache::Registry and ModPerl::RegistryCooker from the
> > same module.) Basically, my module does something like the following (in
> > Apache::PAR::Registry):
> >
> > if(eval "Apache::exists_config_define('MODPERL2')") {
> > @ISA = qw(Exporter Apache::PAR::RegistryCooker);
> > require Apache::PAR::RegistryCooker;
> > }
> > else {
> > @ISA = qw(Exporter Apache::PAR::ScriptBase Apache::RegistryNG);
> > require Apache::RegistryNG;
> > require Apache::PAR::ScriptBase;
> > }
>
> Use a BEGIN {} block?
>
Actually, I was incorrect about what the problem was (sorry, too much
coding, not enough sleep :-)
It looks like the reason that this was failing is that the use fields
pragma requires that all sub-classes involved either 'use fields ...' or
'use base ...'. The reason for this is that 'use base' also modifies
the %FIELDS hash in the current package to include the fields from the
parent package (similar to what my original patch does with "import").
So, I got it working by changing the code to be:
if(eval "Apache::exists_config_define('MODPERL2')") {
eval "use base qw(Apache::PAR::RegistryCooker);";
...
Still kinda ugly in my opinion though. Probably not a very likely case
to have to do this however unless a module is trying to work with both
Apache 1.x and 2.x, but it could lead to some strange looking problems
if someone doesn't follow the directions.
We've had a few emails back and forth now, so below is a summarization
of the features/disadvantages of the two approaches as I understand them
from what we have discussed. Please let me know if I miss anything.
I'll try to be as impartial as possible with the following - actually,
after these emails back and forth, I'm not sure if I have a clear
preference myself anymore :-).
fields Pragma
-------------
Advantages:
* More straightforward approach
* Less code to add to module
Disadvantages:
* Based on pseudo-hashes - may have problems with reloading, etc
* Unknown whether it changes performance (due to "typed lexical"
limitation of pragma)
* Forces developers to 'use base' and/or 'use fields' in sub-class, can
cause non-obvious error otherwise
Array based
-----------
Advantages:
* Easy to change code to change base class implementation in the future
* Good encapsulation (ability to override methods in future without
breaking sub-classes)
Disadvantages:
* Adds a custom non-standard extending technique
* Need to explain method in doco for adding sub-class data (via
"public"), vs. pointing the developer to an existing perl document.
* Doesn't work with multiple inheritance (probably not a big deal for
most RegistryCooker sub-class developers though)
--
Nathan Byrd <[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
