in reply to Re^2: constants in multiple libraries
in thread constants in multiple libraries
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.
|
|---|