All, As promised, here's a link to the proof-of-concept implementation: https://github.com/ircmaxell/php-src/blob/spl_decorator/ext/spl/spl_decorator.c#L77
I'm not really looking for feedback about whether or not we should implement a decorator helper, but more for this exact method of doing it (having a "magic" base class which would be extended)... The interface addition is mainly a quick tool to test it with. I would think that's too dirty to go with in an official proposal. In the official proposal I could foresee two main ways of solving it: 1. Add an additional pointer to the zend_class_entry for the wrapped class. Then change instanceof and the like to check for that pointer as well. 2. Move instanceof to a handler from the current standalone function. Then each (pecl level) class could choose its own implementation if it is needed. The function could still exist for BC reasons, but would proxy to the handler method if it existed... Then, the wrapped class (the additional pointer) would only need to live on the objects internal store... Thanks, Anthony On Mon, Aug 13, 2012 at 7:50 PM, Nicholas Curtis <nich.cur...@gmail.com>wrote: > I agree great idea. Would really help to simplify benchmarking code also. > > On Mon, Aug 13, 2012 at 4:16 PM, Nils Adermann <nader...@naderman.de> > wrote: > > > On 08/12/2012 08:17 PM, Anthony Ferrara wrote: > > > Thoughts? > > Yes, please. I think this would be a great simplification for all kinds > > of extensibility / plugin mechanisms implemented in various PHP projects. > > > > Typically these either end up with the boilerplate you described or try > > to come up with some kind of hack (e.g. dynamic code generation) to > > circumvent the problem of having to explicitly define parent classes if > > one wants to dynamically decorate objects multiple times while maintaing > > interfaces. > > > > Cheers, > > Nils > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >
