I have seen this approach taken before, so there are certainly people out there who will agree with you. However, the point I was trying to make is that Foo.pm should be a package of its own. If Foo.pm were package Foo; and exported &make_foo, then both Bar and main would have access to it without needing to fully qualify the package name.
I feel that is is "sloppy" coding to refer to anything in the main namespace from inside an included package, because it violates encapsulation. When a package depends on methods or variables being defined in its client’s namespace, it becomes more difficult to accommodate. Explicitly referring to main from within a package is even worse because you might not be making assumptions about you're clients namespace, but rather your client's client's client's namespace. Such assumptions will make a code base unstable, and less extensible.
In reply to Re^3: constants in multiple libraries
by JediWizard
in thread constants in multiple libraries
by shemp
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |