http://qs321.pair.com?node_id=251769


in reply to Use module questions..

'/httpd/cgi-bin/module' is an absolute path. It always refers to the same place. '.' is a relative path. If you run the script from a different directory, you won't find your modules.

@EXPORT is what gets exported if the user doesn't request a different export list. If you know what you want exported, specify it explicitly as in your second example instead of relying on the module maintainer to not change @EXPORT.

90% of every Perl application is already written. ⇒
dragonchild

Replies are listed 'Best First'.
Re: Re: Use module questions..
by kiat (Vicar) on Apr 20, 2003 at 03:52 UTC
    Thanks, pfaut!

    So if power.cgi is in a different directory from Test.pm, I should use '.', right?

    And if I want to make the subroutine 'power' available automatically in the main script (i.e. power.cgi), I should include it in our @EXPORT = qw(&power $hello_away);, right?

    If I do that, then I won't need the @EXPORT_OK array. Please let me know if I understood you correctly =)
[reply]
      No - the other way round - if power.cgi is in a different directory to Test.pm, you'll need an absolute path to it ("/httpd/whatever/") or a relative path that will find it ("../../httpd/whatever"). pfaut's point is that if you use a relative path, and then move script.cgi to *somewhere else*, the relative path won't work, so you're probably safer using an absolute path.

      You've sussed it about @EXPORT and @EXPORT_OK though. :)

      Cheers
      Ben.
[reply]

      '.' means the process's current working directory which may or may not be the directory containing the script or the directory containing the module. If you want to make sure you find your modules, use absolute paths.

      The whole idea of namespaces (packages) is to avoid accidentally redefining routines and variables when you use a module. When you export names from a module, you have removed this protection barrier. It's better to use @EXPORT_OK and let the user decide which names to import than to use @EXPORT and force it on him.

      This isn't such a big deal if you're writing both the module and the program that uses it but if you're writing the module for someone else to use it might become an issue. They may not be aware of all of the names you listed in your @EXPORT array. If one of those names clashes with a name they are already using, they may get unexpected behaviour.

      Remember, the user can always get to the routines and variables in the package by specifying the full package name, e.g., $PackageName::PackageVar. Providing it through an export only allows the user to use a shorthand notation.

      90% of every Perl application is already written. ⇒
      dragonchild
[reply]
[d/l]

In Section Seekers of Perl Wisdom