in reply to Re^2: Log::Log4perl and singleton design issue
in thread Log::Log4perl and singleton design issue

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
  • Comment on Re^3: Log::Log4perl and singleton design issue

Replies are listed 'Best First'.
Re^4: Log::Log4perl and singleton design issue
by exussum0 (Vicar) on Dec 19, 2004 at 20:04 UTC
    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.

[reply]
      ... so you can create two, one or three on a whim. The singleton pattern allows control over that.

      1, 2 or 3 instances of a singleton ... m'kay :)

      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
[reply]
[d/l]

        You don't create multiple instances, jsut multiple references. Each part of the program that needs a reference gets its own, so it doesn't have to rely on some other distant part of the program.

        For instance, Apache::DBI does this sort of thing so different things happening in mod_perl can share a database connection, even though they might be different applications.

        --
        brian d foy <bdfoy@cpan.org>
[reply]
        The point is not to hardcode something somewhere. If you wish to use globals, go right ahead. I'm not trying to stop you. Just like you use enapsulation in OO for setters and getters for the flexibility of doing things during sets or gets, it's the same for singletons. It allows you to break the mold. Saying singleton's are useless is like saying sed is useless. If it were useless, people wouldn't use it.

        ----
        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.

[reply]

In Section Seekers of Perl Wisdom