I don't know how you would do that for variables, but for subroutines, you could try AUTOLOAD. However, I wouldn't recommend it. If you are trying to migrate your code from the main namespace to more specialized namespaces, those "method not found" errors are your friends - they tell you that you have missed a dependency that maybe should be moved as well to the new namespace.

To be honest, I'm not sure I've understood your goal. You've moved code from the main namespace to more specialized namespaces, but you still want all of your variables and subs to refer to the main namespace? That doesn't make much sense to me. The normal reason for moving code and variables into namespaces is to provide better encapsulation.

Better encapsulation would mean studying the code to find out what routines call what other routines and variables. Then if a variable $X is only used by sub A(), sub B(), and sub C(), all of which are in namespace Foo, you would move $X to Foo. If sub Y() was also only used by routines in Foo, you would move sub Y() to the Foo namespace as well.

Perhaps you are trying to eventually transition your code to namespaces, and don't want everything to break in the short term? If so, it is better to do these changes incrementally and bottom up. Move one subroutine at a time over to the new namespace. Study its code and make a conscious decision about the namespace for each variable and subroutine consumed by the one you just moved. Does it belong in the new namespace? main? some third namespace?

Start with a low level routine that is essential private to the mega routine that you eventually want to move. When you have moved several routines and variables over to the new namespace, and the mega subroutine has only a handful of dependencies left in "main", then and only then, move the mega routine.

Also be aware that when you move routines to a new namespace, all of the consumers of the moved routine will now need to change their calls to refer to the new namespace (which won't be main). If there are a lot of routines calling X() or you don't have a good way of tracking down all of the callers of X(), you may want to think twice about moving sub X() to a new namespace.

Best, beth

A common solution is to first move subs with no or little dependencies to a module, and then use that module both from the main script and from the other modules you are going to create.

The solution for variables is to rely less on implicitly shared state, but rather pass that information as arguments to the subroutines, or encapsulate it into objects.

#!/usr/bin/perl

use strict;
use warnings;
use Sub::Mutate qw(
        sub_body_type
        sub_closure_role
        sub_is_lvalue
        sub_is_constant
        sub_is_method
        sub_is_debuggable
        sub_prototype
);

my $sub = \&finddeps;

my $type_body          = sub_body_type($sub);
my $type_closure       = sub_closure_role($sub);
my $type_is_lvalue     = sub_is_lvalue($sub);
my $type_is_constant   = sub_is_constant($sub);
my $type_is_method     = sub_is_method($sub);
my $type_is_debuggable = sub_is_debuggable($sub);
my $type_prototype     = sub_prototype($sub);

print 
"$type_body,
$type_closure, 
$type_is_lvalue, 
$type_is_constant, 
$type_is_debuggable, 
$type_prototype\n";  
 
sub finddeps {
    
    use CPAN::FindDependencies;
   
    my @dependencies = CPAN::FindDependencies::finddeps();
    foreach my $dep (@dependencies) {
    print ' ' x $dep->depth();
    print $dep->name().' ('.$dep->distribution().")\n";
  }
}
[download]

No, you should switch paradigms, switch to object oriented programming.