Singletons and global variables are both manifestations of "global state". Generally speaking, global state is the enemy. (And I don't mean that as an anti-UN conspiracy theorist!)

If the global state is mutable (i.e. different parts of the code can alter it), then it can result in spooky action at a distance. Even if it's immutable, it can result in too tight coupling between different bits of code.

It's certainly best to pass into functions all the data they need to do their job, and pass to object constructors all the data the object needs.

It can be cumbersome to pass around database handles from object to object, but there are patterns that can be followed to help eliminate some of these difficulties. For example, say you have a Document object that creates several Section objects, and needs to pass its database handle on to its sections. You might have something like this...

sub get_header {
   my $self = shift;
   Section->new(dbh => $self->dbh, title => "Header");
}
sub get_toc {
   my $self = shift;
   Section->new(dbh => $self->dbh, title => "Contents");
}
sub get_footer {
   my $self = shift;
   Section->new(dbh => $self->dbh, title => "Footer");
}
[download]

This can be transformed into:

sub make_section {
   my $self = shift;
   Section->new(dbh => $self->dbh, @_);
}
sub get_header {
   my $self = shift;
   $self->make_section(title => "Header");
}
sub get_toc {
   my $self = shift;
   $self->make_section(title => "Contents");
}
sub get_footer {
   my $self = shift;
   $self->make_section(title => "Footer");
}
[download]

This means that the dbh pass-the-parcel happens in just one place instead of many. It also makes it easier for subclasses of Document to override the construction of Section objects.

(My module MooseX::ConstructInstance can help with implementing this pattern.)

Whether using Moose or not, I usually solve the problem by defining a single Config.pm unit which exposes a single variable (or, as the case may be, a subroutine).   And so, “here is where all the configuration variables can be found.”   All that you have to do is to use it.

Furthermore, I usually define within that unit a conf(variable, variable ...) subroutine which, given a list of keys as its argument list ... (@_) ... traverses the (otherwise private ...) data-structure which it defines, returning a reference that corresponds to the nested list of keys provided ... and dieing if the (nested...) key cannot be found.   (This makes an otherwise difficult-to-debug problem trivial to spot, and to trace to the exact bit of code that was requesting it.)

The logic within this accessor-subroutine can be as smart or as dumb as it needs to be.   It is simply “the way that everything in the application gets configuration-variables,” and it is equipped to detect and immediately flag any attempts to request undefined keys.   Although my code rarely uses actual “singletons,” this is how I would handle any sort of singleton case:   a well-known public subroutine returns the appropriate reference on-request.

I agree with Anonymous Monk. Pass it as an argument.

If you think that is absolutely not acceptable, you could use a global variable, which you then localize when you need a different one. But sooner or later it is going to byte you.

Pass it as an argument, thats what argument passing is for

See http://perldesignpatterns.com/?SingletonPattern

One option would be a simplistic factory that held a single "shared thing", and was responsible for creating the other objects, so that they could have a reference to the shared thing without having to explicitly pass the "shared thing" around.

Something like this:

#!/usr/bin/perl -w
use strict;
package SharedThing;
sub new {
    my $that  = shift;
    my $class = ref($that) || $that;
    return bless {"counter" => 0}, ref($that) || $that;
}
sub hello {
   my $this=shift;
   $this->{counter}++;
   printf "hello, count is [%d]\n",$this->{counter};
}

package MyFactory;
sub new {
    my $that  = shift;
    my $class = ref($that) || $that;
    my $this = {};
    bless $this, $class;
    $this->{sharedthing}=SharedThing->new();
    return $this;
}
sub A {A->new(@_);}
sub B {B->new(@_);}

package A;
sub new {
   my $that  = shift;
   my $class = ref($that) || $that;
   my $this = {};
   bless $this, $class;
   $this->{factory}=shift;
   # call the "hello" method of the "shared thing" so that
   # we can see that it's indeed a single instance
   $this->{factory}->{sharedthing}->hello();
   return $this;
}

package B;
our @ISA=qw(A);

package main;
my $factory=MyFactory->new();
my $a1=$factory->A();
my $a2=$factory->A();
my $b1=$factory->B();
my $b2=$factory->B();
[download]

All of the instances of A and B have a reference to the factory passed to them when they are instantiated, and so, they can get to $this->{factory}->{sharedthing}...the single shared object.

Thanks everyone for the suggestions!

Looks like passing it to the objects as an argument is the preffered solution. My only issue with that is that I have a relatively large object hierarchy, with something similar to the following objects:

A instantiates B and C
B instantiates D
D instantiates E
[...]
[download]

So now if E needs access to the config module I'll have to pass it all the way down.

Looks like passing it to the objects as an argument is the preffered solution. My only issue with that is that I have a relatively large object hierarchy, with something similar to the following objects:

A instantiates B and C
B instantiates D
D instantiates E
[...]
[download]

So now if E needs access to the config module I'll have to pass it all the way down.

Yes, passing is slightly more typing, but if you don't, then you're accessing a global variable -- which is worse? The following might shed a little light

Why Singletons are Evil - Being Scott Densmore - Site Home - MSDN Blogs , Use your singletons wisely ; Know when to use singletons, and when to leave them behind

So a global app configuration is common use of a singleton ... I've used it, I've seen it used ... I don't really have an informed opinion :)