in reply to aliasing subs

You want caller, But...

Why mess with one code block with two names? Just make two subs, or see File::Spec for a better way to do this job.

Update: broquaint is correct about caller not doing what you want:

$ perl -e'sub foo {print( (caller 0)[3], $/)} local *bar = \&foo; bar( +)' main::foo $ perl -e'$foo = sub {print( (caller 0)[3], $/)}; local *bar = $foo; b +ar()' main::__ANON__ $

After Compline,
Zaxo

Replies are listed 'Best First'.
Re: Re: aliasing subs
by december (Pilgrim) on May 06, 2003 at 11:47 UTC
    Why mess with one code block with two names?

    Because both return values come from the same line of code; and just to practice my perl skills.

    You're right that using a module could be more handy, but I want to understand more about perl references, so I try to use some in my code. I'm more interested in explanation why it does/doesn't work, and what the alternatives in implementation are, than references to modules. ;)

    Thanks for the idea, though.

      sub x { print "Starting with X\n"; my $ret = _shared_code(@_); return "From X: $ret"; } sub y { print "Starting with Y\n"; my $ret = _shared_code(@_); return "From Y: $ret"; } sub _shared_code { # Do stuff here }
      You still get the shared code abstracted out and you get to handle differences. I often do this with structures like:
      sub DoFoo { return do_stuff('Foo', @_) } sub DoBar { return do_stuff('Bar', @_) } sub DoBaz { return do_stuff('Baz', @_) } sub do_stuff { my ($name, ...) = @_; # Do stuff here }
      This is usually one of the first steps I take when refactoring a bloated code base.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.