Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

order of strict and package

by John M. Dlugosz (Monsignor)
on Jun 01, 2001 at 18:59 UTC ( #84944=perlquestion: print w/replies, xml ) Need Help??
John M. Dlugosz has asked for the wisdom of the Perl Monks concerning the following question:

Which is more correct at the top of
use strict; use warnings; package Packagename;
package Packagename; use strict; use warnings;
Does a package affect the "scope" of anything? It has no effect on my/our lexical things.


Replies are listed 'Best First'.
Re: order of strict and package
by DrZaius (Monk) on Jun 01, 2001 at 19:15 UTC
    Generally, it is:
    package PackageName; use strict; use warnings;
    I think this has something to do with the package identifies the file, so it should be at the top. Although, multipackage files break this.

    Also, if you mix up pragma and other modules by accident, symbols will be imported into MAIN and not __PACKAGE__.

    For example:

    use strict; use CGI qw/:standard/; package MyPackage;
    That probably would be a bad thing as it wouldn't be obvious why CGI functions are being imported into your script's namespace.
      Oh, yeah. That symbol importing problem would get REAL ugly. : ) I hadn't even considered that.

Re: order of strict and package
by bikeNomad (Priest) on Jun 01, 2001 at 19:06 UTC
    use strict is lexically scoped, so it takes effect as soon as it's encountered, but can be overridden in an inner block:
    $main = 123; package xyz; use strict; $xyz = 123; package abc; $abc = 123;
    warns about $xyz and $abc but not about $main.
(jeffa) Re: order of strict and package
by jeffa (Bishop) on Jun 01, 2001 at 19:12 UTC
    I always place the package declaration on the first line of a module file. But you can put it anywhere you really want. According to perlmod:
    Typically it [package] would be the first declaration in a file to be included by the require or use operator. You can switch into a package in more than one place;


(tye)Re: order of strict and package
by tye (Sage) on Jun 01, 2001 at 19:42 UTC

    You can put use strict above or below since (as has been said) its effect is lexically scoped. use warnings, on the other hand, (in part) affects the calling package and so needs to come after the package statement.

    For this latter reason, I'd put the package before both of the others.

            - tye (but my friends call me "Tye")
      tye wrote, “use warnings, on the other hand, (in part) affects the calling package and so needs to come after the package statement.”

      How does use warnings affect the calling package?

      The perlmodlib page says that pragmas are either package or lexical, with clues as to how to tell which is which. The docs for use warnings in particular doesn't add to that.

      I can certainly see how something could modify the lexing hints variable and also manipulate the current package's symbol table.

      The documentation in perlvar states that $^H does block scope things, and that is how use strict is implemented. However, use warnings uses ${^WARNING_BITS} and the description for that doesn't say anything similar re block scope restoring.

      If ${^WARNING_BITS} has its value restored at the end of a block, in the same way as $^H, then the normal use warnings/no warnings would not have anything to do with the current package or any influence on the package's contents.


        A simple use warnings; doesn't but more advanced usages of that module do. Sorry, I was misleading.

                - tye (but my friends call me "Tye")
Re: order of strict and package
by needles (Acolyte) on Jun 01, 2001 at 19:37 UTC
    Pragma usage is lexical, so just by looking at the text of the code, you can determine where strict will apply or not. Since package is not a scope-closer (starting a new package, thus closing the old package, won't start a new lexical scope) the strict scope will run right over it.
    use strict; package Strict::Package;
    package Not::Strict::Yet::Package; use strict; # Now it's a strict package
    are almost the same, provided there are no lines between the package and the use line in the second option. (The only difference being that the package declaration itself will not be subject to strict's strictness.) But bear in mind, since the scope of the declaration is lexical, if you declare the strict in another scope, it won't apply. (That is, if you declare strict in another block, loop, eval, file, or subroutine.)
    { use strict; package I::Think::I'm::Strict; } # But I'm really not
    Overall, I would say that I would prefer the first one, but I don't think it makes much of a difference. The only reason why I go for the first option is that if I'm going to use strict, I like to say so right away, so I put that declaration right after the shebang. But even if you put it immediately inside the first package of the file, and then went on to define several more packages in that file, it would apply to all of the packages there, but not to the first package statement itself, if that mattered at all.
Re (tilly) 1: order of strict and package
by tilly (Archbishop) on Jun 01, 2001 at 20:29 UTC
    I tend to break strict in the header. So I write it like this:
    package Packagename; use Exporter; @EXPORT_OK = qw(foo bar); @ISA='Exporter'; use strict; # etc
    Note that I am still working on 5.005_03 so I don't use warnings. (And I won't use our even after upgrading, but that is another story.)
      Tilly, Why do you "break strict" in your header?

      I tend to do the following, and am wondering if I am doing something wrong...

      package Foo; use strict; use Exporter; use vars qw(@EXPORT_OK @ISA $foo $bar); @ISA = qw(Exporter); @EXPORT_OK = qw($foo $bar);
        I used to do that as well. I changed because it is less typing and as a way of hinting that @ISA and @EXPORT_OK are not to be assigned to within the module. YMMV.
      That used to bother me, too. use vars came along, and then the our keyword fixes the problem. Care to tell us (on another thread, if need be) what you find wrong with our "even after upgrading"?
        I already explained at Why is 'our' good?. Basically there is nothing that our does that I don't think can be done better another way.

        Beyond that I avoid introducing gratuitous backwards compatibility issues unless I see a significant gain from the new feature. I simply do not see that in our.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://84944]
Approved by root
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (9)
As of 2017-01-22 18:53 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (189 votes). Check out past polls.