Re^5: Dynamically wrapping ancestor method calls

Ah, I see.

So you could achieve what you want by putting a wrapper function around the return statements of the relevant methods in Audio::XMMSClient.

  return $s->_process_handle($handle);
[download]

where _process_handle just returns its arg for async behaviour or does the sync-wait-and-return-data for the sync behaviour. You could select between the two either by subclassing (and overriding _process_handle), or even passing in sync => 0/1 to the ctor.

If that isn't palatable for some reason, this sounds a little bit like a job for that modern buzzword Aspect Oriented Programming. This isn't really my area of expertise, but as I understand it, it allows you to effectively install pre- or post- handlers into your existing codebase, selected by various criteria. Adding handlers to massage the return values of a given class sounds within it's remit.

I suspect that under the hood it is doing the same symbol table walking we've talked about before, but that should work OK in your case I think.

Comment on Re^5: Dynamically wrapping ancestor method calls Download Code

Replies are listed 'Best First'.
Re^6: Dynamically wrapping ancestor method calls by rafl (Friar) on Dec 12, 2006 at 23:37 UTC
That is indeed a solution that would work. Unfortunately Audio::XMMSClient is written in XS. Therefor adding that wrapper around the according return statements would be somewhat painful unless I add some pure-perl wrapper to all XS functions, which I don't want for obvious reasons. I already thought of using Moose and register a function to be called after a given function, but unfortunately this has the same problem as the subclassing approach: I need to have a list of all relevant functions. But as this changes frequently as the libxmmsclient API isn't stable yet and there have been large changes merged recently in the development branch I don't really want that. Cheers, Flo	[reply]

Replies are listed 'Best First'.

Re^6: Dynamically wrapping ancestor method calls
by rafl (Friar) on Dec 12, 2006 at 23:37 UTC

That is indeed a solution that would work. Unfortunately Audio::XMMSClient is written in XS. Therefor adding that wrapper around the according return statements would be somewhat painful unless I add some pure-perl wrapper to all XS functions, which I don't want for obvious reasons.

I already thought of using Moose and register a function to be called after a given function, but unfortunately this has the same problem as the subclassing approach: I need to have a list of all relevant functions. But as this changes frequently as the libxmmsclient API isn't stable yet and there have been large changes merged recently in the development branch I don't really want that.

Cheers, Flo

[reply]