This will generate those three subs you showed (Update: see Function Templates and Method Names as Strings):

for my $meth (qw/ WriteLine Select Add /) {
    my $sub = sub {
        my $self = shift;
        my $it = $self->OStream->$meth($_[0]);
        $self->Trace(_CallerStr($it));
        return $it;
    };
    no strict 'refs';
    *$meth = $sub;
}
[download]

Optionally put that in a BEGIN { ... } block if you want to be able to call the subs without parens.

Here's a simple wrapper class that uses Autoloading, although autoloading can be a bit dangerous and have some caveats (e.g. the following doesn't overload UNIVERSAL methods like can, although it probably should for completeness; Update: also this example always calls the method in scalar context, although that could be changed by inspecting wantarray; plus obviously wrapper and wrapped objects have completely different classes, so isa and especially ref checks would break), so I would recommend the above solution instead. Use this like my $wrapper = Wrapper->new($object); and you should be able to call the original methods from $object on $wrapper instead. Update 2: I guess I should be more clear that the following is really just a demonstration of the (sometimes scary) power of AUTOLOADing and not something I'd recommend for wide use. You might want to look at something like around from Class::Method::Modifiers instead.

package Wrapper;
use Carp;
sub new {
    my ($class,$wrapped) = @_;
    return bless \$wrapped, $class;
}
sub AUTOLOAD {
    my $wrapped = shift;
    (my $meth = our $AUTOLOAD) =~ s/.*:://;
    croak "Wrapped object $$wrapped doesn't have a method $meth"
        unless $$wrapped->can($meth);
    # do stuff here
    my $returnval = $$wrapped->$meth(@_); # call wrapped method
    # and more stuff here
    return $returnval;
}
sub DESTROY {} # don't autoload DESTROY
[download]

Just pass the method into the sub:

sub Call {
    my $self = shift;
    my $method = shift;
    my $it = $self->OStream->$method($_[0]);
        $self->Trace(_CallerStr($it));
    return $it;
};
[download]

If you want to call the methods by their name without them being defined, there is AUTOLOAD:

our $AUTOLOAD; # needs to be a package global
sub AUTOLOAD {
   $AUTOLOAD =~ s/.*:://; # strip package name
   return if $AUTOLOAD eq 'DESTROY';
   splice @_, 1, 0, $AUTOLOAD; # package/object, method, rest of args
   goto \&Call;
}
[download]

for my $meth (qw/ WriteLine Select Add /) {
    my $sub = sub {
        my $self = shift;
        my $it = $self->OStream->$meth($_[0]);
        $self->Trace(_CallerStr($it));
        return $it;
    };
    no strict 'refs';
    *$meth = $sub;
}
[download]

In this loop $meth and $sub form a so called closure, each instance of $sub is "closing over" a new instance of the lexical var $meth with a string.

This my $it = $self->OStream->$meth($_[0]); takes advantage of the fact that method calls are (contrary to sub calls) late evaluated strings, i.e. resolved at runtime. (for completeness $meth could also be a code_ref but that's not relevant here)

This

    no strict 'refs';
    *$meth = $sub;
[download]

is assigning a code_ref in $sub to the symbol named in $meth via a so called *glob.

That's how the STASH (Symbol Table hASH) works, each varname in a package has a hash key and the value is a "typeglob" with 6 so called "slots". Assigning a code_ref fills the CODE-slot, you can also address other slots like SCALAR, HASH or ARRAY and so on.

This case showed how to fill the %main:: stash, other namespaces need to be provided explicitly.

no strict 'refs' was necessary because using symbolic references like in *$meth (i.e. $meth is a string not a pointer like reference) is forbidden under strict.

This would work right away ...

*pack::name = sub {};

... but your name has to be dynamic.

Thanks for the explanation, I am relatively new to perl and my initial project was only reworking/enhancing existing code. Would you be able to elaborate, or comment, on the benefits of using autosplit for autoload, in that, placing any functions to be called by autoload after __END__ and having autosplit generate the *.al files necessary versus just having the functions inside of the package and having the appropriate method called during autoload? I was able to get both styles detailed, by shmem and Haukex, functional but didn't see any benefit from generating & using the *.al files, but found the simplest implementation was that detailed by shmem.

> Would you be able to elaborate, or comment, on the benefits of using autosplit for autoload

If you are loading code from a slow disk autosplit is faster.

This used to be helpful 20 years ago. ...

Update

If compiling Perl code is slow, just autoloading on demand is faster

Again, this used to be helpful 20 years ago. ... ;)

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)
Je suis Charlie!}