In that case, you might as well make it a true factory and just have:
return Zend_Delegate::factory('Zend_Controller_Request_Http', $parameters);
which queries Zend_Delegate for any user-specified delegates and
instantiates them.
Defining delegates would be specified like this:
Zend_Delegate::setDelegate('Zend_Controller_Request_Http',
'My_Controller_Request_Http');
There's no need to limit it solely to Zend_Db. Any instantiated class in
the framework could be overridden from the bootstrap (so long as its
method signatures matched). This is actually something I'm currently
doing in one of my projects, in a slightly different way (because no
delegating is taking place internally in Zend Framework).
This then would only need to be used with internal code, or for
extensibility-minded open-source developers releasing code based on Zend
Framework. So code-completion concerns aren't so much an issue for the
broader user base.
Also, it probably would be better to just have it at a class-level, not a
method level. Users can just extend a class and add or modify a single
method if they need to.
-Matt
On Thu, March 22, 2007 4:34 am, Mark Gibson wrote:
> There was no intention of it being used for static classes.
> It is purely a generalisation or a standard practice for classes
> that instantiate objects, and allow the class of these new objects
> to be changed. Zend_Db_Table_Abstract has these methods that
> manage this:
>
> [...]
>
> public function select()
> {
> $class = Zend_Factory::getClass(__CLASS__, 'select');
> return new $class();
> }
>
> Then we can register an alternative/subclass of Zend_Db_Select using
> something like:
>
> Zend_Factory::setClass('Zend_Db_Adapter_Abstract', 'select',
> 'MyAlternativeSelect');
