http://qs1969.pair.com?node_id=1146903


in reply to Re^3: Behavior of 'our' variables in the package-namespace
in thread Behavior of 'our' variables in the package-namespace

Actually, all you're putting off is running the import (which in an OO class you aren't likely to be running anyway). All of the code sitting at the class level will still run ...

Not when the require() happens inside a conditional in the library consumer, which is what I was getting at. There's no point (and in fact it can't work) to call require() or use() for packages provided inline, so I presume both of us aren't talking about that case.

Consider the following structure shown below. The entire Foo:: package (and in fact the module file itself) is only loaded if the conditional is hit. This can be demonstrated by running an strace(1) (or your system's equivalent) against a call to that program both without, and then with the "load" parameter. This parameter in fact causes the module to be conditionally loaded, including the BEGIN code defined in the module.

File: consumer.pl

use strict; use warnings; use lib 'lib'; my $arg = shift // ''; if ($arg eq "load") { print "Now loading optional library.\n"; require Foo; my $o = Foo->new; # Do stuff with $o here.. } else { print "I skipped loading the optional library.\n"; print "Try passing the 'load' option to load it.\n"; }

File: lib/Foo.pm

package Foo; use strict; use warnings; BEGIN { printf "BEGIN called from package %s\n", __PACKAGE__; } print "Class level logic.\n"; sub new { my $class = shift; $class = ref($class) || $class; # subclass boilerplate. print "constructor invoked for $class\n"; return bless {}, $class; } 1;

Replies are listed 'Best First'.
Re^5: Behavior of 'our' variables in the package-namespace
by SimonPratt (Friar) on Nov 04, 2015 at 16:58 UTC
    Consider the following structure shown below. The entire Foo:: package (and in fact the module file itself) is only loaded if the conditional is hit.

    Yeah, I see where you're coming from. As I said, its a style thing.

    Personally I don't like it because it means users of the package then have to decide whether they want to keep their own script simple (all dependencies up the top) and simply pay the performance price, or go to extreme lengths to firstly understand where the performance penalties are coming from (which of potentially many packages, assuming this style is adopted everywhere) and then do something to handle it (usually resulting in scripts with difficult to find dependencies). The whole idea behind OO is that you encapsulate your data and code into separate classes. To me that also means making sure your classes don't shit all over the place until they have been instantiated.