Re: More then one AUTOLOAD in a class hierarchy.

This works but we loose the CONTENT of $AUTOLOAD coming in Parent::AUTOLOAD.

Then why not just set it?

$Parent::AUTOLOAD = $AUTOLOAD;
$self->Parent::AUTOLOAD(@_);
[download]

I do something similar to this when i make proxy classes in IOC::Proxy. The proxy class catches the AUTOLOAD and allows you to log it (or whatever you want your proxy to do) and then passes it to the actual object it is proxying.

Of course this way requires you to know what superclass you want to dispatch too. A more generic solution would involve going through the @ISA array and calling AUTOLOAD on each superclass (if they have an AUTOLOAD that is). The code might look something like this (note: this is highly untested)

if (we can do something) {
   ...
}
else {
   no strict 'refs';
   foreach my $super (@{'${class}::ISA"}) {
       my $method;
       if ($method = $super->can('AUTOLOAD')) {
           ${"${super}::AUTOLOAD"} = $AUTOLOAD;
           return $class->$method(@_);
       }
   } 
}
[download]

Of course this would only go down one level of the tree, unless this code was included in the AUTOLOAD on each level of your object hierarchy. A recursive solution would start getting really hairy (as if this wasn't hairy enough).

But now I ask you, is all this really worth it to save a little bit of repetitive typing by hand-making getters and setters?

-stvn

Comment on Re: More then one AUTOLOAD in a class hierarchy. Select or Download Code

Replies are listed 'Best First'.
Re^2: More then one AUTOLOAD in a class hierarchy. by ced (Initiate) on Nov 11, 2004 at 19:18 UTC
I define the attributes of the object just in the overloaded new method.Thus in one place. Setters and getters are handled centrally by the Parent. So that is not just saving typing it is keeping it compact and avoiding lines and lines of not really value added code. Let the machine do the boring work and you do the thinking. Is that not the real way of being lazy? :=) Thanks for your thinking.	[reply]
Re^3: More then one AUTOLOAD in a class hierarchy. by stvn (Monsignor) on Nov 11, 2004 at 22:57 UTC
I define the attributes of the object just in the overloaded new method.Thus in one place. Setters and getters are handled centrally by the Parent. So that is not just saving typing it is keeping it compact and avoiding lines and lines of not really value added code. So then all your attributes are public? And attributes which are defined by Parent::Child and Parent::Child::GrandChild are handled by code in the parent? Which means that code in Parent is directly accessing fields which don't belong to it. This is actually bad OO, and just because perl's (some would say broken) OO system lets you do it, does not mean you should do it. My personal approach (and I am known to be a (sometimes) overly defensive programmer so take it with a grain of salt) is that I never create getters and setters until I actually see a need for one. And IMO it is bad OO design to have your superclass deal with anything which is specific to your sub-class. Your superclass should never need to have any knowledge or deal with attributes of your sub-classes in any way (regardless of how dynamic the code which makes it possible). Let the machine do the boring work and you do the thinking. My argument is that you shouldn't need to actually do the "boring" work unless your "thinking" tells you that it is nessecary. At which point you can implement whatever it is in a reasonable amount of time and not have to do it again. Is that not the real way of being lazy? No. The real way of being lazy is to do it right the first time (more work up front), so that you don't have to do it again when you realize it's wrong. AUTOLOAD is an oft abused feature of perl's (akward) OO system. IMO it should be used with great caution, and only when nessecary. It's mis-use has tripped up many an perl programmer experienced and in-experienced alike. The simple fact that it negates any meaningful use of `can` is IMO enough to not use it. -stvn	[reply] [d/l]