obviously, using the constant TESTCONST in script.pl works as expected

Actually, that's not so obvious from what you've written so far. use Test::Test1; on its own should not cause TESTCONST to be exported from Test::Test1 into the current package unless there is additional code you haven't told us about, such as if you're using Exporter or your script.pl begins with package Test::Test1;. (Update 2: Ok, as per your reply, you don't have a package Test::Test1; at the top of Test1.pm, that explains it too. I wrote this post with the assumption that your Test1.pm begins with package Test::Test1;.)

Is there an overview about which of the various "use ..." statements

Unfortunately, no. There are some rough rules of thumb, such as modules whose names are lowercase are "pragmas" and their effect is often (but not always!) lexically scoped (warnings and strict being the two most common), and regular modules will usually at most export a few functions into your package (although there are lots of exceptions to this rule of thumb). So the short answer is you'll have to look at each module's documentation to see what useing it will do. The long answer is:

Once you understand what's going on under the hood, the mechanisms that Perl uses for modules and pragmas are actually relatively transparent in that there isn't a ton of magic involved, and one can see all the moving parts. When you use a module that you write yourself, here's a rough overview of the mechanisms involved:

  1. When you write use Test::Test1;, then what Perl actually does is BEGIN { require Test::Test1; Test::Test1->import(); } (documented in use), and what require does is explained in detail in its docs, but simplifying a bit, it will search for a file named Test/Test1.pm in the directories listed in @INC and parse and run that file if it hasn't previously done so. Usually, this file will contain a package Test::Test1;, although there is no hard requirement for this. Then, Test::Test1->import() means to call the sub import in the package Test::Test1, passing the string "Test::Test1" as the first parameter (a "class method"), and if there are any parameters in the use statement after the module name and version, pass those as the remaining arguments to import. So you see the basic mechanism here is finding a file, loading it, and calling a sub in that file, which is then free to do whatever it wants, and this is where the "magic" of ex/importing happens.
  2. While you can write a sub import yourself*, that's uncommon because there are several standard implementations, a very common one being the one provided by Exporter. So if in your package Test::Test1; you have written our @ISA = qw/Exporter/;, use base 'Exporter';, or use Exporter 'import';, then your package will be getting Exporter's sub import. What Exporter's import will do is, again very simplified, take the subs and variables you have listed in the package variable @Test::Test1::EXPORT (among others), and install those in the package that called the sub import, i.e. in the package that called the use.
  3. Now as for your question, the effect of use warnings; is limited to the enclosing lexical scope, which in this case is the file, which is why it only affects your Test1.pm. The effect of use constant TESTCONST => 1; is to set up a sub TESTCONST () { 1 }, which means that just like any other sub this definition should be limited to the current package (it is Test::Test1::TESTCONST()), unless you've set up an export/import mechanism like the one I described above to copy it out of that package and into whatever package script.pl uses (main by default).

So you can have modules that export functions in the way I described above, you can have modules that export nothing (usually OO modules), or your own custom "pragmatic" modules that, like warnings, only have an effect in the current lexical scope (documented in perlpragma), or even mixes of these kinds of modules. A close reading of perlmod and the other documentation referenced therein should explain most of this in more detail. Because Perl is very flexible in what it allows module authors to do, it isn't easy to give some general rules as to how modules act, beyond some guidelines and best practices about how modules should be written, and based on that some rules of thumb of what to expect. So you'll have to look at the documentation of each of the modules to see what effects useing them will have. Luckily, most modules have good documentation and the "Synopsis" and further descriptions at the top will usually tell you right away.

I have dozens of scripts which all should use the same basic settings

The recent thread Code Reuse and the threads linked therein (like use y) should help you there. In particular, I have myself used Syntax::Collector and it's a nice module. The only minor drawback is that it uses Exporter::Tiny instead of Exporter, so you can't export variables, only subs (including constants). And just for completeness, here's the code that does what you want without using an extra module:

package Test::Test1; use warnings; use strict; use constant TESTCONST => 123; use base 'Exporter'; our @EXPORT = qw/TESTCONST/; sub import { warnings->import; strict->import; __PACKAGE__->export_to_level(1, @_); return; }

Then, in code that does use Test::Test1;, warnings and strict are enabled and sub TESTCONST is exported as well.

* Update: The basis of what most sub import implementations do is described in the section "Symbol Tables" in perlmod - basically you take the entry for the sub whatever in the current package, &Current::Package::whatever, and copy it to the symbol table of the target module (e.g. main), so that both &main::whatever and &Current::Package::whatever refer to the same piece of code. For completeness, here is an extremely minimalistic implementation of sub import, but this is the basis of what Exporter and related modules do:

our @EXPORT = qw/ ... /; sub import { my $callerpackage = caller; for my $export (@EXPORT) { no strict 'refs'; *{$callerpackage."::".$export} = \&{$export}; } }

In reply to Re: Which "use" statements in a module do "bubble up" to the callers? (updated) by haukex
in thread Which "use" statements in a module do "bubble up" to the callers? [SOLVED] by Nocturnus

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.