http://www.perlmonks.org?node_id=670482


in reply to Code style advice: where to put "use" statements?

It does have the notional affect of stating that the module's use is limited, by convention rather than scoping, to the subroutine.

However, there is nothing to enforce that, so the usage could 'leak', which could be construed as misleading. And what would you (they) do if a module is subsequently needed in another subroutine in the same file?


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.
  • Comment on Re: Code style advice: where to put "use" statements?

Replies are listed 'Best First'.
Re^2: Code style advice: where to put "use" statements?
by tirwhan (Abbot) on Feb 27, 2008 at 10:20 UTC
    And what would you (they) do if a module is subsequently needed in another subroutine in the same file?

    Unless the other subroutine is in a different package it doesn't matter whether it also "use"s the module or not, it's loaded and will be available (I think you are probably aware of this, just putting it in as clarification). See this example

    #!/usr/bin/perl use strict; use warnings; mainsub(); secsub(); thirdsub(); Frob::fourthsub(); sub mainsub { use Data::Dumper; } sub secsub { my $r = "secsub"; print Dumper $r; } sub thirdsub { use Data::Dumper; my $r = "thirdsub"; print Dumper $r; } package Frob; sub fourthsub { my $r = "thirdsub"; print Dumper $r; }
    Output:
    Name "Frob::Dumper" used only once: possible typo at useuse.pl line 31 +. $VAR1 = 'secsub'; $VAR1 = 'thirdsub'; print() on unopened filehandle Dumper at useuse.pl line 31.

    IMO there are several very good reasons not to put "use" into a subroutine (or other block) but rather at the top of a package:

    • It obfuscates which modules you are using, one has to hunt through the entire file to find out which modules are loaded.
    • To make this more confusing, if the file contains multiple packages one needs to limit ones search to just that package, which requires thought instead of just editor-fu
    • Programmers unfamiliar with the compile-time loading property of "use" might be surprised/confused about symbols from that module being available in other subroutines
    • Conversely, programmers who come to rely on just sticking "use" anywhere in a file might be surprised that it's not available in a different package (this goes for putting "use" underneath the package declaration as well, but at least here the ordering gives a hint that the two are relevant to each other).

    All dogma is stupid.
      there are several very good reasons not to put "use" into a subroutine (or other block)

      I was pretty convinced already, but your list settles the matter for me.

      That said, for those not convinced that every abstraction is best served by being OOified, the notion of block-scoped imports is tantalising. Makes me wonder if a new pragma--say: uselocal Some::Module qw[ :stuff ]; wouldn't be possible.

      Unlike require, the module would be loaded at compile time, but the import list would not be processed until runtime.

      At runtime, the import list would be processed per use, but the callers package would be localised (and self initialised) first so that imports would disappear at close of block.

      The problem is how to localise a hash entry within the scope of the caller?

      BTW: I love your tagline. It's duality reminds of the old standby "this statement is false". Comtemplating it brings to mind the nightmares I had as a kid when I realised the implications of the infinity of space.


      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.