I also ran into this problem with Zend_Db_Select. I wanted to add a new
constant to improve my usage of Zend_Db_Table#select(), but that method
would always returns an instance of Zend_Db_Table_Select which extended
Zend_Db_Select. There was no easy way for me to add my class constant
without
The challenge of never use extend is that simply wrapping classes in
decorators only goes so far. You can't always maintain interface compliance
if you're nesting decorators, and if you're overriding only one out of a dozen
or two methods then you have a lot of foo() { return $obj-foo(); }
On Mon, Mar 15, 2010 at 2:14 PM, Larry Garfield la...@garfieldtech.comwrote:
The challenge of never use extend is that simply wrapping classes in
decorators only goes so far. You can't always maintain interface
compliance
if you're nesting decorators, and if you're overriding only one out of
On Monday 15 March 2010 03:08:28 pm Nate Gordon wrote:
If there were a syntactic-level support for wrap this object in this
class and pass through any method that isn't redefined, a sort of
sideways extends,
that would become much simpler. I'm not sure what that would look like,
On 15 March 2010 21:43, Larry Garfield la...@garfieldtech.com wrote:
On Monday 15 March 2010 03:08:28 pm Nate Gordon wrote:
If there were a syntactic-level support for wrap this object in this
class and pass through any method that isn't redefined, a sort of
sideways extends,
that would
This is a good use of the decorator pattern. Let's say you don't like the
way Zend_Form_Element filters form names. You can decorate it with a Your
own class which overrides this, and whenever you add a new element to your
form, decorate it with this class.
On Sat, Mar 13, 2010 at 10:10 AM,
