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

In reply to Re: Checking more than just the current namespace for sub and var definitions by ELISHEVA
in thread Checking more than just the current namespace for sub and var definitions by willjones

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.