Well if you want to change your configuration depending upon the context, then of course you don't want a singleton... which is all about never changing (or overriding) anything wherever you are.

No it isn't. A singleton is about there only ever being one instance of a class. Nothing wrong with having a singleton instance whose state you can change.

Of course it's globals in disguise, but it's globals on steroids too, because you can share your globals across packages as needed :)

Of course you can share globals across packages.

{ package Foo;
  $foo = 1;
}
{ package Bar;
  print $Foo::foo, "\n";
}
[download]

Well you're right I wasn't very clear :) You may of course change a singleton, but changes to it are obviously global to your app. If that's not what you want, then you don't want a singleton.

Of course you can share globals across packages.

Yeah sure, but in an OO-environment that means you're breaking encapsulation. Singletons don't.

You may of course change a singleton, but changes to it are obviously global to your app. If that's not what you want, then you don't want a singleton.

But you might! The singleton class pattern isn't synonymous with static configuration. There are other uses for singletons.

Yeah sure, but in an OO-environment that means you're breaking encapsulation. Singletons don't.

Tell me how do singleton's break encapsulation any more/less than a set of package variables? If you're using them to return static configuration information (as you seem to be proposing) then they encapsulate exactly the same thing.