Scope of subroutines with same name

atemon has asked for the wisdom of the Perl Monks concerning the following question:

Hi,
I have a special requirement where I ended up in defining a subroutine with same as another subroutine already existed. I found like one instance is never executed and I fixed by renaming my subroutine. But I wish to know why its behaves like this. If any monks can help me, it will be great.

My package looks like

package tests;

sub new{
        bless {},shift;
}

sub myfunction_one{

        print "This is myfunction_one\n";

        sub myfunction_two{
#I never remember this sub existed
                print "This is myfunction_two Inside\n";
        }

        &myfunction_two();
}


sub myfunction_two{
# This is my sub, but I renamed it to fix the issue

        print "This is myfunction_two Outside\n";
}
[download]

My perl script looked like

#!/usr/bin/perl

use tests;
my $obj = new tests();

$obj->myfunction_one();
$obj->myfunction_two();
[download]

Output :

This is myfunction_one
This is myfunction_two Outside
This is myfunction_two Outside
[download]

I expected the subroutine "myfunction_two" defined inside the sub "myfunction_one" to execute when I call $obj->myfunction_one();. I expected an output like:

This is myfunction_one
This is myfunction_two Inside
This is myfunction_two Outside
[download]

Is there way in which I can have both subroutines with same name and invoke them independently without conflict? I request you to help me in understanding what is happening there. Thank you in advance for the help.

Cheers !

--VC

Comment on Scope of subroutines with same name Select or Download Code

Replies are listed 'Best First'.
Re: Scope of subroutines with same name by Joost (Canon) on Feb 05, 2009 at 23:42 UTC
Two things are going on here: 1. named subroutines have package scope. it doesn't matter if you declare them inside braces, or another sub, there will always be just one sub with any given name in a single package. anonymous subs don't have this restriction, since they don't have names. 2. subroutines are normally compiled before execution of anything else. Combined, these two rules mean that the last subroutine (which is the bottom one in this example) is the one that's active when myfunction_one is called. In general, it also means declaring nested named subroutines is only going to be confusing. This is one of the areas where perl just isn't as consistent as we'd like it to be, but since it's not clear what the really good solution is, and it's fairly easy to work around the problems it causes, don't expect this to be "solved" in perl 5. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re: Scope of subroutines with same name by ikegami (Patriarch) on Feb 05, 2009 at 23:40 UTC
Don't nest named subroutines. You'll just get problems. Didn't you notice any "%s will not stay shared" warnings? Didn't you notice any "subroutine %s redefined" warnings? You've already noticed it isn't scoped as you expected. I use `sub recursive { ... local *helper = sub { ... helper(...) if $cond; ... }; ... helper(...); ... }` [download]	[reply] [d/l]
Re: Scope of subroutines with same name by almut (Canon) on Feb 05, 2009 at 23:41 UTC
Subroutine definitions in Perl are always package-global — there is no such thing as nested subroutine definitions. Later definitions (with the same name) simply override earlier ones (`"use warnings"` would've told you, btw, that `myfunction_two` is redefined).	[reply] [d/l] [select]
Re: Scope of subroutines with same name by Lawliet (Curate) on Feb 05, 2009 at 23:42 UTC
I believe it is bad practice to have a subroutine inside a subroutine (for the reason you ran into). It makes you think that it is lexically scoped when it actually gets parsed at compile-time. What problem do you have that you need to have two subroutines with the same name? And you didn't even know bears could type.	[reply]