Consider this code, which defines a code reference along with other
references (also see Item 59. Compare reference types to prototypes). You can print the values in most reference types to see what they are, but you can’t do that directly with the code reference:

use v5.10;

my @array = ( \'xyz', [qw(a b c)], sub { say 'Buster' } );

foreach ( @array ) {
	say "$_";
	when( ref eq ref \ ''   ) { say "Scalar $$_" }
	when( ref eq ref []     ) { say "Array @$_" }
	when( ref eq ref sub {} ) { say "Sub ???" }
	}

When you dereference a value, nothing happens (aside from any tie magic). When you dereference a subroutine, you run its code with whatever arguments you give to it. If the subroutine needs arguments, which arguments would you use if you wanted to see what the subroutine would do?

There’s a clever way around this, first noted by Randal Schwartz in his Perlmonks post Track the filename/line number of an anonymous coderef. He proposed a new subroutine, main::Sub to use in place of the sub keyword.

BEGIN {
  package MagicalCoderef;

  use overload '""' => sub {
    require B;

    my $ref = shift;
    my $gv = B::svref_2object($ref)->GV;
    sprintf "%s:%d", $gv->FILE, $gv->LINE;
  };

  sub main::Sub (&) {
    return bless shift, __PACKAGE__;
  }
}

This technique actually made the code reference an object so he could overload stringification.

my $s = Sub { say +shift };
print "$s\n";

This stringified the code reference as the filename and line number where you created it:

/Users/Buster/Desktop/magic_coderef.pl:19

You can go farther than this, though, and make this a bit more useful. In response to Randal’s post, I suggested turning the idea inside-out. Instead of using Sub, I exposed the object creation. That way, you don’t have to worry about which package Sub might be in:

use v5.14;

package MagicalCodeRef 0.90 {
    use overload '""' => sub
        {
        require B;

        my $ref = shift;
        my $gv = B::svref_2object($ref)->GV;
        sprintf "%s:%d", $gv->FILE, $gv->LINE;
        };

    sub enchant { bless $_[1], $_[0] }
    }

You can apply this magic to code references that you already have to get the same result (you could also do this with Sub, but it looks odd):

my $s = MagicalCodeRef->enchant( sub { say +shift } );
print "$s\n";

Still, that’s not good enough. You where where you created the subroutine, but that might not be enough information for you. You can use even more B magic. The B::Deparse module can decompile code to show you what perl thinks it is (we used this briefly in Item 7. Know which values are false and test them accordingly).

use v5.14;

package MagicalCodeRef 1.00 {
    use overload '""' => sub
        {
        require B;

        my $ref = shift;
        my $gv = B::svref_2object($ref)->GV;

		require B::Deparse;
		my $deparse = B::Deparse->new;
		my $code = $deparse->coderef2text($ref);

        my $string = sprintf "---code ref---\n%s:%d\n%s\n---",
        $gv->FILE, $gv->LINE, $code;

        };

    sub enchant { bless $_[1], $_[0] }
    }

With the same bit of code, you get additional output:

my $s = MagicalCodeRef->enchant( sub { say +shift } );
print "$s\n";

The output shows everything that perl thinks it needs to reproduce that behavior, including some pragma settings and compiler hints:

---code ref---
/Users/brian/Desktop/magic:25
{
    use strict 'refs';
    BEGIN {
        $^H{'feature_unicode'} = q(1);
        $^H{'feature_say'} = q(1);
        $^H{'feature_state'} = q(1);
        $^H{'feature_switch'} = q(1);
    }
    print shift();
}
---

The code doesn’t look the same as the code reference you initially created, but at least you have an idea what the code reference does.

If the code reference is a closure, you might also need to know which variables it closed over and what their values are. You can get these from the PadWalker module (which doesn’t come with Perl so you’ll need to get it from CPAN):

use v5.14;

package MagicalCodeRef 1.01 {
    use overload '""' => sub
        {
        require B;

        my $ref = shift;
        my $gv = B::svref_2object($ref)->GV;

		require B::Deparse;
		my $deparse = B::Deparse->new;
		my $code = $deparse->coderef2text($ref);

        require PadWalker;
        my $hash = PadWalker::closed_over( $ref );

		require Data::Dumper;
		local $Data::Dumper::Terse = 1;
        my $string = sprintf "---code ref---\n%s:%d\n%s\n---\n%s---",
        $gv->FILE, $gv->LINE,
        $code,
        Data::Dumper::Dumper( $hash );

        };

    sub enchant { bless $_[1], $_[0] }
    }

Give this new version of MagicalCodeRef a closure:

my $sub = do {
	my( $x, $y ) = qw( Buster Mimi );

	sub { print "$x $y @_" }
	};

my $s = MagicalCodeRef->enchant( $sub );
say $s;

Now you see that which variables in the code reference refer to lexical variables that are out of scope instead of package or special variables. Only the lexical variables show up in the Dumper output:

---code ref---
/Users/brian/Desktop/magic:35
{
    use strict 'refs';
    BEGIN {
        $^H{'feature_unicode'} = q(1);
        $^H{'feature_say'} = q(1);
        $^H{'feature_state'} = q(1);
        $^H{'feature_switch'} = q(1);
    }
    print "$x $y @_";
}
---
{
  '$y' => \'Mimi',
  '$x' => \'Buster'
}
---

Things to remember

• You can bless code references and overload their stringification to output what you like
• The B module can tell you the filename and line number where you created the closure
• The B::Deparse module can decompile a code reference
• The PadWalker module can give you the closed-over
  lexical variables and their values.

The benefit of a scalar reference comes when you realize that perl is stack-based. That is, when it wants to pass things to a subroutine, it puts things on a stack and calls the subroutine. The subroutine takes the right number of things off the stack, does its processing, and puts its return values on the stack. The caller takes the return values off the stack and the program continues. Moving those data onto and off the stack can involve quite a bit of copying.

When you call a subroutine, perl really only puts pointers to the data on the stack. These aren’t pointers in the C sense, but we use the word to distinguish it from Perl’s specialized definition of “reference”. It’s not until you want to assign the values to variables that perl has to copy the original data to initialize the new variables. This lazy initialization is a performance optimization perl uses to avoid copying data it doesn’t need to. When you unpack your argument list into variables, you copy the data into the variable.

Here’s a sequence of events that shows that you make several copies of the same data when you pass a string as an argument, store it in a temporary variable, and then return the unchanged string. This example uses a short string of abc replicated 10 times, but imagine this to be a large XML document or something similarly daunting:

use Devel::Peek;
use 5.010;

my $old_version = 'abc' x 10;
say Dump( $old_version );

my $new_version = copy_string( $old_version );
say Dump( $new_version );

sub copy_string {
	my( $copy ) = @_;
	say Dump( $copy );
	$copy;
	}

The output shows that you made three different copies of the same data, one each for the original, the temporary variable in the subroutine, and the return value. It’s the address after PV = and right before the string that shows the location of the data (rather than the location of the variable). In this case, those addresses are 0x219490, 0x2194b0, and 0x219430:

SV = PV(0x801080) at 0x80f680
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x219490 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

SV = PV(0x801028) at 0x81b3d0
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x2194b0 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

SV = PV(0x8015f8) at 0x80f670
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x219430 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

There’s a way, not necessarily a best practice, that people use to get around that first copy. When you use @_ directly, you use and affect the original data because you actually use the original data instead of a copy of it. That’s why you sometimes see people use it directly in subroutines to change data in place:

use Devel::Peek;
use 5.010;

my $old_version = 'abc' x 10;
say Dump( $old_version );

my $new_version = copy_string( $old_version );
say Dump( $new_version );

sub copy_string {
	say Dump( $_[0] );
	$_[0];
	}

However, since copy_string modifies its argument in-place, you don’t need the return value.

use Devel::Peek;
use 5.010;

my $old_version = 'abc' x 10;
say Dump( $old_version );

copy_string( $old_version );

sub copy_string {
	say Dump( $_[0] );
	$_[0];
	}

Now the output shows that $old_version and $_[0] are the same data (just not equivalent strings). Notice that the address of the two variables (0x801080 in this case) are the same. That’s the special aliasing magic:

SV = PV(0x801080) at 0x80f680
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x219440 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

SV = PV(0x801080) at 0x80f680
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x219440 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

Using @_ directly might be fine for very light jobs, but what if the argument list is more complicated? You don’t want track the position of the argument in @_.

Instead, you use a scalar reference. The argument list contains a real Perl reference, so you aren’t copying anything other than the connection to the data.
You can store the reference value in a named variable without making a copy of the end values:

use Devel::Peek;
use 5.010;

my $old_version = 'abc' x 10;
say Dump( $old_version );

my $new_version = copy_string( \$old_version );

sub copy_string {
	my( $ref ) = @_;
	say Dump( $$ref ); # deref to see data, not ref to it
	}

The output shows essentially the same effect as using @_ directly:

SV = PV(0x801080) at 0x80f680
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x2042f0 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

SV = PV(0x801080) at 0x80f680
  REFCNT = 3
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x2042f0 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

The advantage with a reference is that you won’t unintentionally make a copy when you store the value in a variable. Say, for instance, that you need to call another subroutine and pass along one of the arguments, and that second subroutine store it in a temporary variable:

use Devel::Peek;
use 5.010;

my $old_version = 'abc' x 10;
say Dump( $old_version );

copy_string( $old_version );

sub copy_string {
	say Dump( $_[0] );
	another_sub( $_[0] );
	}

sub another_sub {
	my( $string ) = @_;
	say Dump( $string );
	}

Now you’ve made a copy of the data in another_sub:

SV = PV(0x801080) at 0x80f680
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x21d250 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

SV = PV(0x801080) at 0x80f680
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x21d250 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

SV = PV(0x801028) at 0x81b4e0
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x204340 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

If you passed along references instead, it’s always the same reference so there’s no danger of creating another copy:

use Devel::Peek;
use 5.010;

my $old_version = 'abc' x 10;
say Dump( $old_version );

copy_string( \ $old_version );

sub copy_string {
	my( $ref ) = @_;
	say Dump( $$ref );
	another_sub( $ref );
	}

sub another_sub {
	my( $ref ) = @_;
	say Dump( $$ref );
	}

The output shows only one copy, even though you used two different temporary variables:

SV = PV(0x801080) at 0x80f680
  REFCNT = 1
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x219350 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

SV = PV(0x801080) at 0x80f680
  REFCNT = 3
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x219350 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

SV = PV(0x801080) at 0x80f680
  REFCNT = 4
  FLAGS = (PADMY,POK,pPOK)
  PV = 0x219350 "abcabcabcabcabcabcabcabcabcabc"\0
  CUR = 30
  LEN = 32

Things to remember

• perl makes copies of data when you assign it to different variables.
• Pass scalar references as arguments to avoid unnecessary string duplications.
• You can modify variables in-place through references.

my @copy = @original;

This is a bad habit that new Perl programmers pick up because they are only dealing with flat arrays: that is, every value is a simple scalar, so they never see the problem:

my @original = qw( Buster Ginger Mimi Ella );

my @copy     = @original;

If you know that you have only a flat array, that’s not a problem. However, the experienced programmer knows that “you know” is often the source of misguided assumptions that blow up later.

At the Learning Perl level, we conveniently skirt the issue because we don’t talk about references until Intermediate Perl. That’s right: blame me.

Consider the case where one of the array elements is a reference. As long as you don’t change the values, you don’t see the problem:

my $buster      = {
	name => 'Buster',
	colors => [ qw(black white) ]
	};
my @original = ( $buster, qw( Ginger Mimi Ella ) );

my @copy     = @original;

printf "In \@original, the first cat's name is %s\n", $original[0]->{name};
printf "In \@copy, the first cat's name is %s\n", $copy[0]->{name};

The output doesn’t show anything out of place:

In @original, the first cat's name is Buster
In @copy, the first cat's name is Buster

Now change one of the values in @copy:

my $buster      = {
	name => 'Buster',
	colors => [ qw(black white) ]
	};
my @original = ( $buster, qw( Ginger Mimi Ella ) );

my @copy     = @original;

$copy[0]->{name} = 'Roscoe';

printf "In \@original, the first cat's name is %s\n", $original[0]->{name};
printf "In \@copy, the first cat's name is %s\n", $copy[0]->{name};

The output now shows both arrays were affected even though you only wanted to change @copy:

In @original, the first cat's name is Roscoe
In @copy, the first cat's name is Roscoe

Instead of an assignment, which is the source of your problem, make a deep copy. There are several ways that you can do this. The dclone
function (for deep clone) from Storable (part of the Standard Library) can do it for you:

use Storable qw(dclone);

my $buster      = {
	name => 'Buster',
	colors => [ qw(black white) ]
	};
my @original = ( $buster, qw( Ginger Mimi Ella ) );

my $copy     = dclone \@original;

$copy->[0]{name} = 'Roscoe';

printf "In \@original, the first cat's name is %s\n", $original[0]->{name};
printf "In \@copy, the first cat's name is %s\n", $copy->[0]{name};

Now the output shows that the two arrays remained distinct:

In @original, the first cat's name is Buster
In @copy, the first cat's name is Roscoe

You had to make one subtle change to your program, however. dclone takes a reference and returns a reference, so you didn’t copy @original to another array variable. That’s not very nice. You could copy the de-referenced value:

my @copy     = @{ dclone \@original };

That’s not very pretty either. You could hide that in a subroutine, but the easiest thing is to just give over to references and use them everywhere from the start (but that’s another Item for another time):

use Storable qw(dclone);

my $buster      = {
	name => 'Buster',
	colors => [ qw(black white) ]
	};
my $original = [ $buster, qw( Ginger Mimi Ella ) ];

my $copy     = dclone $original;

$copy->[0]{name} = 'Roscoe';

printf "In \$original, the first cat's name is %s\n", $original->[0]{name};
printf "In \$copy, the first cat's name is %s\n", $copy->[0]{name};

Set aside the issue named variables to consider a more common case where that reference element in your array is an object. Here’s the simple class that implements a simple Cat:

BEGIN {
package Cat;

sub new {
	my( $class, %hash ) = @_;
	bless \%hash, $class;
	}

sub set_name { $_[0]->{name} = $_[1] }
sub get_name { $_[0]->{name} }
}

Converting your previous problematic program to use Cat, you have:

my $buster      = Cat->new(
	name => 'Buster',
	colors => [ qw(black white) ]
	);
my $original = [ $buster, qw( Ginger Mimi Ella ) ];

my $copy     = $original;

$copy->[0]->set_name( 'Roscoe' );

printf "In \$original, the first cat's name is %s\n", $original->[0]->get_name;
printf "In \$copy, the first cat's name is %s\n", $copy->[0]->get_name;

Again, the output shows that you changed “both” objects:

In $original, the first cat's name is Roscoe
In $copy, the first cat's name is Roscoe

Using dclone solves the problem:

my $buster      = Cat->new(
	name => 'Buster',
	colors => [ qw(black white) ]
	);
my $original = [ $buster, qw( Ginger Mimi Ella ) ];

my $copy     = dclone $original;

$copy->[0]->set_name( 'Roscoe' );

printf "In \$original, the first cat's name is %s\n", $original->[0]->get_name;
printf "In \$copy, the first cat's name is %s\n", $copy->[0]->get_name;

Now you have two separate objects, each with distinct values:

In $original, the first cat's name is Buster
In $copy, the first cat's name is Roscoe

There’s an additional problem here though. Simply cloning an object might not be the right thing. What if the object has database connections, open filehandles, or other bits that should be properly re-initialized? What if the object is actually a singleton, so you end up with a copy anyway? You can add a clone method to your class to handle that, and we’ll cover that in a later Item.