The problem is that choosing a singleton early on, while seemingly convenient, makes changes later on much harder.

If you model your app properly first, this shouldn't happen.

How is it different when we're using a singleton to store static configuration information? Both are encapsulating the configuration information in one place (package variable vs object instance variable).

But a variable encapsulate nothing at all! if I feed my configuration singleton from a flat file, and later I switch it to use XML, or a database, or whatever, I'll still use it the same way :

$singleton->param($somedata)
[download]

That's what's called encapsulation, right ? Accessing variables directly may work if you read only, but writing would be a complete mess...

About the only place where a singleton class might buy you something is if you're configuration information is determined at runtime. That's the only extra bit of implementation you can hide more easily with a OO based solution.

If your configuration data is strictly static, then you have no reason not to write it in the code directly in the first place, right ?

The problem with sprinkling ConfigClass->instance->whatever everywhere in your code is exactly the same problem you get with sprinking $ConfigClass::whatever around everywhere. Really tight coupling that makes testing and refactoring a PITA.

It's a problem IF you can't easily switch configurations. Testing when you haven't tooled your code to be tested is hard anyway.