It was me who asked that question on #perl.

I could not think of a clean solution to solve that problem using subclassing. Therefor I now use a pattern like this:

sub new {
    my $class = shift;

    my $obj = SomeClass->new( @args );

    bless \$obj, $class;
}

sub AUTOLOAD {
   ...;
   $$self->$meth( @_ );
   ...;
}
[download]

This creates a wrapper class around the class I initially tried to subclass and delegates all method calles to the inside object using AUTOLOAD. This works pretty well so far.

Cheers, Flo

You should probably try to figure out what to do with "implicitly defined" methods in your wrapper class, like can() and isa(). My skills don't allow me to either try to suggest something intelligent, or to assure that these two methods are the only ones that you get for free when you create a wrapper like this. Moreover, you should be sure that the already existing methods don't play with caller() (you could try to read Hook::LexWrap to figure out how to deal with this issue).

Update: from chromatic's answer, I assume that I actually got all the implicitly defined subs :)

Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf

Don't fool yourself.

sub can
{
    my $self = shift;
    ${ $self }->can( @_ )
}

sub isa
{
    my $self = shift;
    ${ $self }->isa( @_ );
}
[download]

rafl,
I intentionally didn't mention you specifically because you didn't post here when I suggested you to. Avoiding subclassing all together was one way I thought of too. I still want to know if anyone has a clean way of doing it as originally asked. Sometimes innovative thinking comes from unexpected places.

Minor wording updates

Cheers - L~R

You'd lose out if anyone did anything as gross as installing methods in the superclass at methods at runtime, but who would abuse perl like that ;-) <-- Note ironic smiley.

jbert,
You could and that is one of the ideas put forward. Do you know how it would work if you had more than one ancestor before you got to UNIVERSAL? I don't know of all the issues but it seems like there would be more than just what would happen if the symbol table was modified at runtime.

I am not sure there is a good answer, that's why I asked. To state it a different way, how can I overide perl's method resolution process and insert my own.

Cheers - L~R

If you assume that the symbol tables of your superclass tree aren't going to change, you could scan them in the same order that perl does (recursively take @ISA from each one and walk up the hierarchy), and thus build up a complete list of possible methods on the subclass.

Since that ordering is documented, you aren't really abusing internals knoweldge to do that.

It seems to me that that should work. It still isn't very nice though. I still like the proxy object, actually. That seems to work pretty well.

Out of interest, may I ask about the the original problem which is being addressed by the automagic wrappering?