in reply to defined &{ $pkg . '::foo' } vs. $pkg->can( 'foo' )

Thanks for all the replies. The problem that served as context for the question is to devise an automatic way to define delegated methods.

A typical "delegated method" looks something like:

sub frobozz { my $self = shift; return $self->{ _delegate }->frobozz( @_ ); }
...where $self->{ _delegate } holds a reference to some other object. The first object basically passes the buck to the delegate.

My basic idea was to run through all the "public methods" that the delegate can perform (by plucking them out of its and its ancestors' symbol tables) and define a delegated method (like the one illustrated above) for each of those methods among these that the containing class cannot perform.

The fly in the ointment, of course, is that fishing functions out of symbol tables, in general, cannot distinguish between public methods (which are part of the delegate's API) and private methods or functions that have been imported by the delegate class, and neither of which belong to its API.

The only thing I can think of is that, if all the ancestor classes are ones that I control, then I can define those classes so that their private methods are easy to distinguish (e.g. with leading underscores) and so that they don't import anything. They either use fully qualified function names, or do something like:

BEGIN { *_croak = \&Carp::croak; }
I.e. import a function "by hand" but rename it in such a way that it can be easily filtered out.

(Or I can go nuts and assign all these non-API methods to lexical scalars.)

And yes, the whole scheme described above would miss any AUTOLOADed or runtime-defined methods of the delegate object. Again, I don't know a way around this, other than avoiding using such methods in those classes I control.

I suspect that, as is my habit, I am complexifying things... As always, your comments are most welcome.

the lowliest monk

Replies are listed 'Best First'.
Re^2: defined &{ $pkg . '::foo' } vs. $pkg->can( 'foo' )
by tlm (Prior) on Jul 15, 2005 at 02:38 UTC

    OK, here I'm replying to my reply to a post of mine. Pretty solipsistic... Never mind me.

    One could argue that automating the generation of delegated methods should give off some pungent code-smell... Why? Because the only rationale for it is for the delegating class to be able to "track" the delegate class's API automatically, but if that's the case, maybe the delegating class should be inheriting instead. In other words, one could argue that the portion of a class A's API that is delegated to another class B should be decided by the designer of class A, irrespective of the changes in class B's API. (Of course, class B's API could shrink, which could in turn break some delegated methods, but IMO it is far more likely that, if it changes at all, the API of class B will grow, not shrink.) Therefore, instead of having class A automatically figure out which methods to delegate to the delegate class, these methods should be hard-coded in the definition of class A. This obviates the problem of distinguishing those functions in the delegate class's and its parents' symbol tables that belong to the delegate class's API from those that don't...

    the lowliest monk