Take for instance an object that used semaphores and locking to prevent multiple people exuting at once. For instance, a banks total available funds, not per account basis. One person would want to withdraw $50, but you don't want to create race conditions.

If taking out money starts to create contention, you can create pools of bank totals so that multiple people can withdraw and deposit at the same time without race conditions, and less contention. If $5 million were broken out into pools of $1 million, 5 people could withdraw and deposit at the same time w/o creating a race condition provided each person got a different object, one for each of the million. As pooled items aren't needed, they can be put away and dealocated.

Where does this all lead up to? If you use the singleton pattern, everyone would use the single, lockable object. If locking becomes a problem, then you can change the code in whatever creates your singleton instances to create a limit of 5 pooled objects. If all 5 are in use, you have to wait. if 4 are in use, you get a new one. Basically, a pool, as you and I know of. Using the pattern will result in less code change. If you use a global, you can't accomplish this. If you are using a singleton, it's a lot easier. In some OO languages, this is very easy to implement. In others, it takes foot work. But by far, it is not useless.

There is no reason that the global in question cannot be an object. And no reason that object shouldn't actually represent a pool of things, performing locking, or whatever else you might require under the covers.

Global is about scope, not encapsulation. If the resource has application wide usage, there is no reason that it should not have application wide scope. That the resource is an object (or represented by an object) is neither here nor there.

Once you accept that an object that has application wide scope, is just a.n.other object with global scope. It's just another object that gets instantiated early in the program and lives for the life of the program. How it is implemented, a single thing, or a pool of things is irrelevant.

The 'singleton pattern' makes a special case where no special case is needed.

Of course, if the needs are simple, then I'd probably use a glob for logging, and if the needs became more complex, then I'd tie the glob.

---

Examine what is said, not who speaks.        The end of an era!

"But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
"Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo         "Efficiency is intelligent laziness." -David Dunham
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

Yes, but you make it function accessable so you can create two, one or three on a whim. The singleton pattern allows control over that.

----
Give me strength for today.. I will not talk it away..
Just for a moment.. It will burn through the clouds.. and shine down on me.

A global is a global, and wrapping it in a 'singleton pattern' and having to make a long-winded, slow and repetitious call to get your hands on it each time you need to use it is pointless.

Well, you don't have to make the call everytime - you can just call once for each logger you need and cache the result. The fact that get_logger($logname) always returns the same object for the same logname is just a convenience. It has very little to do with object oriented programming (except maybe for the terminology).

The practical value is the interface which defines how you log things.

If you use a global variable, then everywhere you want to log something you have to use that particular global variable. You've just tightly coupled all that code. If you decide to change how things work, you have to change a lot of code. With a method call, you don't have to know ahead of time what's you're going to get or how it's implemented. All of that stuff is hidden by the method call. Once you separate yourself from the implementation, you can change it without having to go through the rest of your code to maintain the tight coupling.

You still want to pass around references because you want every thing working with the same copy of things, and any changes apply to every thing that uses it. Since you want a reference, it's not too much of a leap to use one that's been blessed.

You don't need a slow or repititous call either. You make your own package that represents the logger. Behind that is all the gory details. When you decide to switch from L4p to something else, your code doesn't need to know that. The class name and the name of the logger aren't global variables: they are symbolic constants. They represent things you hard-coded (or determined) somewhere else so you don't have to know what it is ahead of time. Behind that package you figure out how to implement it, and are free to change the decision without rippling changes through the code base.

my $log = Log->new( SYMBOLIC_CONSTANT );
[download]

The Singleton is a way to control access without giving people direct access. When I use them, the actual object is a lexical variable in its package. Anyone who wants a reference to it has to go through the interface. They can't futz with package names. They get their reference to it, store it in whichever variable they like, and get on with life. You don't get that control with package variables.

I made no critisism of Log4Perl. My expressed opinion was limited soley to the "singleton pattern".

The OP gave reference

Anywhere I need to log something, I call get_logger() and then call my methods, typically without a temporary variable in the style of Log::Log4perl->get_logger("logger_name")->log("message").

In that, he is hard coding two invarients all over his codebase: "Log::Log4perl" & "logger_name". By doing so, he is creating a maintainance problem.

One solution is to confine those invarients to a single place by making the call once at the top level of his application and sharing the log object returned with the deeper levels of code via a global. Another is to hide the invarients behind a package global in the form of a function name. Both perfectly practical, sensible solutions.

The thing I noted is that either of these will work just as well with a standard object (class), or even a (tied) glob and the "singleton pattern' has achieved nothing.

That is because the solutions offered override the 'singleton pattern', whose sole purpose is to avoid sharing through globals (even if disguised behind a function interface). In order to be using the 'singleton pattern' as it is intended, it is necessary to re-aquire access to the singleton resource, via it's interface, at each point (or scope) in the application. Each class in the application should instantiate it's own instance of the logger either on-demand, or as a instance (or class) variable (or method).

Following the 'singleton pattern' therefore requires embedding the invarients in multiple places. Either within the constructors of all the classes that will use the resource, or in the parameters to those constructors.

You've suggested that this embedding of invarients in multiple places can be avoided by using a symbolic constant, which I agree is another perfectly practical solution, but all you have done is to move the invarient behind a different label--which also has global scope.

A rose by any other name...

I also suggest that all these solutions work equally well if the class of the logger object is any normal class that, given the same values to it's constructor returns the same instance. The 'singleton pattern' servers only to make a special case of something that doesn't need a special case.

It is also the case that all the various ways of allowing code to be written to share a single resource, without hardcoding the name of that resource all over the codebase, could equally return a glob. And by returning a glob rather than an object, it would allow the users of the logger to use all the standard Perl tools available for formatting, and print(f)ing to globs, rather than having to reinvent these in each module, or rely on the logging object to provide methods for access to all of them.

It would also allow programs that start off logging to a file they opened in the normal way, to 'upgrade' to using the logger, by simply tieing the glob to the logging object, instead of opening the file. So retroactively gaining access to all the features of the logger without having to recode each individual line of logging to use an alternative interface.

---

Examine what is said, not who speaks.        The end of an era!

"But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen
"Think for yourself!" - Abigail        "Time is a poor substitute for thought"--theorbtwo         "Efficiency is intelligent laziness." -David Dunham
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon