in reply to Module for executing postponed initialization code
I use two approaches for this.
Either, a module documents and exports an explicit initialization routine:
package Foo; my $dbh; sub init_foo { my( %script_config )= @_; # Read config file ... # Connect to database $dbh ||= $config{ dbh } || connect_to_foo_database( %script_config + ); # Set up cache ... };
Alternatively, I construct these things when they are first needed:
sub frobnicate { my( $self, %options )= @_; $options{ dbh } ||= $self->get_dbh; ... }; sub get_dbh { my( $self )= @_; $self->{ dbh } ||= do { DBI->connect( $self->{dbi_parameters} ); }; };
The approach is more explicit in the sense that things fail early, but it needs the explicit call by the person writing the script.
The other approach is more implicit in the sense that things only get initialized once they are needed.
I don't like the implicit magic of having a special name for the module which is called to configure things.
If I had to implement such magic, I would have something like this:
package Module::MagicInit; use strict; my @init_queue; sub register_init { push @init_queue, [ (caller(1))[2], @_ ]; }; sub init { for my $task (@init_queue) { my( $package, $callback, @args )= @$task; $callback->( @args ) or die "Init failed for $package."; }; };
... and then use that like so:
package Foo; use Module::MagicInit; register_init( \&my_init, 'Hello', 'World' ); sub my_init { my( $greeting, $name )= @_; print "$greeting, $name\n"; }; 1;
#!perl -w use strict; use Module::MagicInit; ... Module::MagicInit::init();
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Module for executing postponed initialization code
by Dallaylaen (Chaplain) on Nov 20, 2014 at 13:17 UTC |