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

Hi, I was wondering about the scope of required/used modules. A project I'm working has a large number of dependencies, and I'm afraid that they will cause some undesired results.(Although there exists no circular dependencies) Below is two minor examples to illustrate my point:

(Bold letters are modules, means 'X' requires 'Y')

A ---> B

A ---> C

C ---> B

Q: Why can module B access A or C content?

Q: Can A access B content without requiring B directly? (Since it is an implicit link there already)

Q: If a module is required twice, is there any mechanism like in C++ that can check if a module is required twice and in that case skip any redundant require's ?

In another example I might have a sequential list of modules:

A ---> B

B ---> C

C ---> D

A ---> D

Q: Is the last require of A to D redundant? i.e. Can A access D without it?

Two other general questions:

Q: Is there any "best practices" for how you require/use modules?

Q: Can I use the naming convention 'module' and 'package' interchangeably or is there any significant difference?

Replies are listed 'Best First'.
Re: Scope of required modules
by JStrom (Pilgrim) on Aug 30, 2008 at 13:23 UTC
    Q: Why can module B access A or C content?

    Each package doesn't have its own instance of perl. When a module requires C, the C namespace is populated. Requiring a module is not that different from saying "our $C::foo" Any code that asks to see the C namespace can see every variable within it.

    Q: Can A access B content without requiring B directly?

    Yes, but don't do that. It will be a pain for future programmers to figure out what's going on.

    Q: If a module is required twice, is there any mechanism like in C++ that can check if a module is required twice and in that case skip any redundant require's ?

    See "perldoc -f require" Require records the modules it finds in %INC and will ignore redundant requests.

    Q: Is the last require of A to D redundant? i.e. Can A access D without it?

    No, it tells the next programmer that A intends to use D and keeps them from murdering you when they can't figure out where these D::foo methods are coming from. And if C ever changes its internal format to stop using D the code will still work.