in reply to 'use' inside or outside of package declaration?

I would not put 'use warnings;' on top. But that has nothing to do with package. There's a difference between:
use Module; use warnings;
and
use warnings; use Module;
If Module has user defined warnings, the first one enables them, the second doesn't.

Replies are listed 'Best First'.
Re^2: 'use' inside or outside of package declaration?
by John M. Dlugosz (Monsignor) on May 11, 2011 at 07:48 UTC
    So, putting use warnings as far down as possible (after the module includes) can enable the most warnings?

    But Moose and 5.12 both enable warnings so we don't need to say it again... maybe that's not strictly true? Checking perldelta, it says 5.12 turns on strict. But I thought Moose and various "modern" boilerplates turn on warnings, and would do so fairly early.

    It would be more awkward to have multiple packages defined in one file, if they used different modules and thus had different custom warnings available to them, since warnings pragma isn't scoped to the package. Normally I would not have multiple packages except for one-offs or an internal object that's very simple, but needs to be blessed.

      So, putting use warnings as far down as possible (after the module includes) can enable the most warnings?
      Yes. I was bitten by this recently, but now I'm struggling to find an example of where it matters.
      But Moose and 5.12 both enable warnings
      Neither use 5.12;, nor use 5.14; (5.14 is scheduled to be released today) enable warnings. Some people have proposed that use 5.16; enables warnings.

      Question: does no Moose; turn off warnings?

        5.14 is scheduled to be released today
        Unfortunately, it seems it isn't. There's a newly discovered regression from 5.12.

        expect 5.14 on 14.5.2011 :-)

        Footnote

        The above regression has been patched while I was composing this node, and we now have RC3 in git.

      But Moose and 5.12 both enable warnings
      No, 5.12 most assuredly does not. I guarantee this.

      And that Moose continues to do so is a design flaw so serious that it really cannot be considered anything less than a genuine bug.

      Modules that act like Acme:: modules without being in that namespace are a problem.