> I really don't think [the proposed Zend_Log::debug() method]
> is a good replacement for Zend::dump.

I agree.  However, I think having a method for dumping objects to a log is
good to have in tandem with the existing, simple dump() function.  Both
would preferably be made available through a Zend_Debug class.

> OK, make it get() and put() - but it should be *easy*. It should not
> require knowing about singletons and instances. The concept of putting
> and getting variable in registry is simple, so should be acting on this
> concept in framework. If you want to do complex stuff (like having
> multiple registries) then it can be complex, but easy actions should be
> done by easy code. That's why we have SimpleXML - that's why we should
> have SimpleRegistry and SimpleDump :)

In any event, whenever you're dealing with the registry, it's rarely just
getting a single value out of it.  It's getting multiple values (Cache,
Db, View, etc.).

Compare:

$registry = Zend_Registry::getInstance();
$cache    = $registry->cache;
$db       = $registry->db;
$view     = $registry->view;

vs.

$cache = Zend_Registry::get('cache');
$db    = Zend_Registry::get('db');
$view  = Zend_Registry::get('view');

The first example seems easier to me.

Anyway, you only need to instantiate the object once in each controller's
init() method.

public function init()
{
    $this->_registry = Zend_Registry::getInstance();
    // Or $this->_registry = $this->getInvokeArg('registry');
}

> Errr? So we went all this long way with registry - only to get back to
> global variables? If I wanted global variables, why would I need
> Framework anyway? What's the added value there?

No one's suggesting using a global variable, only that it is possible to
use Zend_Registry in many different ways.  I prefer to pass it as an
invocation argument to the front controller, which makes it available to
all actions.  Most others probably prefer the Singleton interface.

You mentioned that new users will find the Singleton pattern confusing. 
If someone isn't familiar with basic design patterns, they'll probably
find the internals of most of the components in the framework confusing or
mysterious.  For example, the front controller (it uses a Singleton as
well).  But just because users might not understand the internals doesn't
mean they can't use it.  That's what the manual is for.

-Matt

Reply via email to