Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Do I have to export all variables and functions from my PM file?

by SergioQ (Beadle)
on Mar 05, 2022 at 20:07 UTC ( [id://11141861]=perlquestion: print w/replies, xml ) Need Help??

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

My Perl PM has the following lines of code:

our @itemsArray = qw( sheet_no sheet_name item ); our $itemsArraySize = @itemsArray; our @itemRecords; our @ISA = qw(Exporter); our @EXPORT = qw( getTopHTML getBottomHTML ssPrintTable $domainname msgInTable LogInToDB LogOutOfDB createRandonNumber createRawDB printLine alertSupport insertItem getRecords );

And I've wondered if I must export functions, strings, arrays, etc. etc. that are not used ouside of the PM module? Obviously I have already played with it both ways, and I have had no headaches. But that doesn't mean it's the proper way.

So that's my question: If I don't use a specific variable outside the PM itself, do I need to export it?

That includes an array, which the PM might return an array reference to the calling perl script. My limited knowledge of Perl recalls that Perl knows if a variable is still in use and will keep it alive if necessary, but again, I learned only as much Perl as I needed to get some very limited scripts written.

Thank you

Replies are listed 'Best First'.
Re: Do I have to export all variables and functions from my PM file?
by afoken (Chancellor) on Mar 05, 2022 at 21:20 UTC
Re: Do I have to export all variables and functions from my PM file?
by LanX (Saint) on Mar 05, 2022 at 20:21 UTC
    > So that's my question: If I don't use a specific variable outside the PM itself, do I need to export it?

    No, to the contrary:

    You shouldn't because you are needlessly polluting the namespace.

    Furthermore it's normally better not to export on default, but to populate @EXPORT_OK instead.

    And exporting variables is considered bad practice, only export subs.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

      For some background on the principles behind the LanX's excellent points, see Information hiding -- the general idea is to hide your module's implementation (which is likely to change over time) from the (possibly many) programs that call it. So don't just blindly export all your module's variables! Instead, think harder about designing a good module interface, one that will stand the test of time, and so allow you to make many future module improvements without needing to update in step all your programs that use it.

      This topic is discussed in much more detail at: On Interfaces and APIs

        As long as you don't make it too hard to modify the behaviour of your code, that is. Also see the discussion on How to redefine a modules private function?.

        perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'

      In fact, it is probably better to make the variables lexical (i.e. 'my' rather than 'our'). The 'our' variables are still accessible using their fully-qualified names. The 'my' variables are not accessible at all from outside the scope that declares them, unless some code in that scope passes them out.

        Yes, in general one is better off to
        • always default to private vars with my
        • only use public our when really needed

        But this is not always so, there are always exceptions to the rule.

        Some modules use package vars for external config, e.g. Text::Glob or Data::Dumper °

        Some even export readonly vars to be used as constants (instead of barewords without sigils)

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery

        °) of course TIMTOWTDI, these design patterns date back to the Perl4 times, which had neither OOP nor private lexical vars. Data::Dumper for instance has a dual API.

        The 'my' variables are not accessible at all from outside the scope that declares them, unless some code in that scope passes them out.

        PadWalker

Re: Do I have to export all variables and functions from my PM file?
by stevieb (Canon) on Mar 06, 2022 at 02:42 UTC
    If I don't use a specific variable outside the PM itself, do I need to export it?

    No. In fact, please don't export variables at all. Use functions that access the variables, and export them instead.

    To further, the names you're using lead me to believe that this is a good candidate for an Object Oriented module, therefore you won't have to export anything at all, plus you'll get the added benefit of being able to keep state within your objects.

Re: Do I have to export all variables and functions from my PM file?
by syphilis (Archbishop) on Mar 05, 2022 at 23:55 UTC
    And I've wondered if I must export functions, strings, arrays, etc. etc. that are not used outside of the PM module?

    I just want to point out that (as you may already know) functions, package variables and package constants can all be accessed from the "outside" even if they're not exported. They just have to be accessed via their fully qualified names - eg My::Mod::foo() instead of simply foo(), $My::Mod::package_var instead of $package_var and My::Mod::CONST_VAL instead of CONST_VAL.

    Cheers,
    Rob

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://11141861]
Approved by LanX
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (9)
As of 2024-03-28 23:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found