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

I would think that if the package line itself used syntax that did not work in older perls, then the use or feature would certainly have to come first!
That’s an interesting point. As of 5.14, you can do this:
package NAMESPACE VERSION;
That sets the appropriate version number in that namespace, at compile time, and in a declarative fashion so that the toolchain doesn’t have to run (or simulate running) the code just to ascertain the package’s version number. It is also superior in that it puts the version number right at the top where it belongs, guaranteeing that it won’t drift down in the module as time goes by, as so often seems to occur.

And that’s not all. You can also do this:

package NAMESPACE BLOCK
To create a lexical scope smaller than that of the rest of the file scope for the package declaration to govern. And of course you may combine these:
package NAMESPACE VERSION BLOCK
If you’re going to do this, it does make some sense to put a use 5.014 before that in your code. With all the myriad differences in Perl that have come about in the 5.10, 5.12, and 5.14 releases, I’ve for some time now taken to prominently placing a use 5.012 (or whatever) as the first thing in the file. It’s a way of declaring the version of Perl that I developed and tested the code under, and an indication that I have no intention of backporting and testing and maintaining it on Perls older than that.

Replies are listed 'Best First'.
Re^2: 'use' inside or outside of package declaration?
by John M. Dlugosz (Monsignor) on May 12, 2011 at 11:15 UTC
    I'm putting
    use 5.10.1; use utf8;
    as the very first things. I'm not afraid of very old perls not liking the dotted syntax since the installer already checked the version once. I agree, this documents the version I wrote it under and tested it under, and can ensure some backward compatibility if even newer ones changed things.

    The meaning of utf8 in modern versions is simply to state that the source file is UTF-8. That really really affects the entire file, not a block, not a package.

    Based on what I learned on this thread, I'll put other stuff after the module's package line. I'm trying autodie for example, and I had supposed that to be more global and not per-package, but it was on your list.

    As for the referenced ranteditorial concerning warnings in production servers, I think that ought to be fixed once and for all in the logging system. Just piping stderr to a file and archiving that file is rather brute simple. I've worked on systems where logging was more engineered. At the very least it has quotas with purging so it won't fill up the disk!

      My current semi-working boilerplate for new programs tends to look like this:
      #!/usr/bin/env perl use 5.012; # want unicode strings! use utf8; use strict; use autodie; use warnings; # defer FATAL till runtime use open qw< :std :utf8 >; use charnames qw< :full >; use File::Basename qw< basename >; use Carp qw< carp croak confess cluck >; $0 = basename($0); # shorter messages $| = 1; binmode(DATA, ":utf8"); # give a full stack dump on any untrapped exceptions $SIG{__DIE__} = sub { confess "Uncaught exception: $@" unless $^S; }; # now promote run-time warnings into stackdumped exceptions # *unless* we're in an try block, in which # case just generate a clucking stackdump instead $SIG{__WARN__} = sub { if ($^S) { cluck "Trapped warning: @_" } else { confess "Deadly warning: @_" } };
      But that suffers form a couple of bugs. There is a bug in the implementation of autodie that screws up the layers imposed by use open. Witness:
      % perl -e 'use open qw(:std :utf8); open(F, ">/tmp/out"); print F "\xD +F"'; wc /tmp/out 0 1 2 /tmp/out % perl -e 'use autodie; use open qw(:std :utf8); open(F, ">/tmp/out"); + print F "\xDF"' ; wc /tmp/out 0 1 1 /tmp/out % perl -e ' use open qw(:std :utf8); use autodie; open(F, ">/tmp/out") +; print F "\xDF"' ; wc /tmp/out 0 1 1 /tmp/out
      The other problem is that use utf8 doesn’t really work well on globals, because there are issues with how the package symbol tables are accessed as byte strings. There is also an issue of what to do about something like:
      use Weather::El_Niño;
      That has to map to the filesystem, and now what do you do? Just use the bytes as they are? Normalize to UTF‑8? Downgrade to Latin1 (which it might have already been)? Did you know that (for very good reasons) the Darwin HSF+ filesystem always converts filenames into NFD, their canonically decomposed form? So be careful when checking filenames!! You can’t just say:
      @files = grep { /Niñ/ } glob("{El,La}_*");
      
      Because if you input it in the normal way, your pattern is going to have a U+00F1 LATIN SMALL LETTER N WITH TILDE there (which is the NFC form) but the results from the filesystem will have an "n" followed by U+0303 COMBINING TILDE (the NFD version), which is suddenly two separate code points, not one.

      There is a Google Summer of Code project for cleaning up Perl’s tokenizer vis‐à‐vis 8‑bit names, including for UTF‑8. I am convinced that this can and shall be fixed.


      I see my stalker is back. Yawn!

        Just a note: Darwin HSF+ uses NFD (with some deviations), not NFC. I've been bitten by it, you cannot even do
        touch á cat á
        in the shell.
        I'll study that some more later in the day.

        use strict is redundant since 5.12 includes that.

        As for file names, don't forget Windows uses UTF-16 in its API. The characters has well-defined meanings (not just bytes), but it still suffers from Normalization issues.

        binmode(DATA, ":utf8"); That's not implied by the utf8 pragma?

Re^2: 'use' inside or outside of package declaration?
by BrowserUk (Patriarch) on May 12, 2011 at 16:05 UTC
    it does make some sense to put a use 5.014 before that [the package line] in your code.

    Now you see, that is rational thinking. I knew you were capable of it.

    It does make sense to use some pragmas before the package statement in a module.

    They may be few and far between, and require you to test that the positioning works as you'd want and expect it to, but such pragmas do exist.

    And strict is one of them. Chosen through a process of applied rationality, in direct contrast with blanket imposition of dogma every bit as bad as that which you (rightly) rail against.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.