in reply to Dynamically wrapping ancestor method calls

Couldn't you walk the superclasses' symbol table to build a list of methods that need wrapping (and then install corresponding methods in the subclass?). Perhaps at first subclass 'new' time, to capture any init-time dynamic methods in the superclass?

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.

  • Comment on Re: Dynamically wrapping ancestor method calls

Replies are listed 'Best First'.
Re^2: Dynamically wrapping ancestor method calls
by Limbic~Region (Chancellor) on Dec 11, 2006 at 17:47 UTC
    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

[reply]
      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?

[reply]
[d/l]
        Out of interest, may I ask about the the original problem which is being addressed by the automagic wrappering?

        I'm the author of Audio::XMMSClient. This module provides an asynchronous interface th xmms2's client library. This is quite powerful but not very easy to use, especially very simple scripts or unit tests which don't need the async interface most of the time.

        Therefor I wanted to write a wrapper, Audio::XMMSClient::Sync, around it that does just the same as Audio::XMMSClient does on all method calls, except for those which return some kind of request handle to be used in asynchronous clients. In that case it should just block until the request is completed, unpack the response into some perl structure and return that.

        That way code that looked like that with the async api..

        my $con = Audio::XMMSClient->new(...);
$con->connect or die $con->last_error;

my $res = $con->medialib_get_info( $some_song );
$res->wait;
my $value = $res->value;

        [download]

        becomes that..

        my $con = Audio::XMMSClient::Sync->new(...);
$con->connect or die $con->last_error;

my $value = $con->medialib_get_info( $some_song );

        [download]

        Cheers, Flo

[reply]
[d/l]
[select]
        jbert,
        WRT the original problem, perhaps rafl can explain. When I pressed further on IRC there was no response. Presumably this is because rafl was AFK working on alternatives.

        Cheers - L~R

[reply]

In Section Seekers of Perl Wisdom