It retains the same meaning whereever you refer to it in your code, and thus you can't change the "object" without affecting every part of your entire application, that depends on it. The access modifiers doesn't change that.
That pretty much constitutes a global in my taxonomy.
In that sense, it very much is a global, but it is still an object as well; no different than using a singleton.
Ok. Then why would Zend want to wrap it further? If it already has an API aren't you just obscuring it by adding another layer?
Zend_Db is a database abstraction object which uses pdo as a means to connect to the database. Zend_Db, for example, allows one to determine table structure regardless of the underlying rdb. Something that pdo does not do.
Data Mapper - a class with knowledge of a) a business object class and b) the database which this object should be persisted in. It is used to persist a business object which has no knowledge of how to persist itself. As defined by Fowler, this includes the business object having no knowledge of the Data Mapper itself. The purpose of the Data Mapper is to allow for the business object and the database schema to evolve independently. The price you pay for this independance is the added complexity of the Data Mapper itself.
It seems to me that Fowler doesn't sufficiently distinguish the complexity of the pattern itself from the complexity of the task it performs. The Data Mapper pattern does not add much complexity in and of itself. A simple Data Mapper that handles only one database table is only marginally more complex than the other patterns. The real complexity comes from performing complex mappings involving multiple database tables, inheritance, etc.
Dagfinn Reiersøl PHP in Action / Blog / Twitter "Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
Actually I was thinking of Ruby and Python, but it applies to JS as well. The odd thing I've found about JS is how, if you use a variable without declaring it, it automatically belongs to the global scope. Seems like an odd design decision to me, although there's probably a good reason I'm not thinking of.
You're right, there is a good reason, and it's called closures. Granted, they could have implement closures in another way, but they decided this is simpole enough. And it's just yet another reminder that each language should be considered on its own merits; focusing on similarities in syntax and other things can often be dangerous.