Re: [PHP-DEV] Decorators Revisited

2012-08-13 Thread Stas Malyshev
Hi! > 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 add

Re: [PHP-DEV] Decorators Revisited

2012-08-13 Thread Anthony Ferrara
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

Re: [PHP-DEV] Decorators Revisited

2012-08-13 Thread Nicholas Curtis
I agree great idea. Would really help to simplify benchmarking code also. On Mon, Aug 13, 2012 at 4:16 PM, Nils Adermann 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 mec

Re: [PHP-DEV] Decorators Revisited

2012-08-13 Thread Nils Adermann
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

Re: [PHP-DEV] Decorators Revisited

2012-08-13 Thread Benjamin Eberlei
Just seeing my previous reply only went to Anthony in person. so i have to repeat here: Its an awesome idea, i really like it :) On Mon, Aug 13, 2012 at 9:10 PM, Jordi Boggiano wrote: > Heya, > > > What do you think? Is this a route that I should continue down? Or is > there > > something funda

Re: [PHP-DEV] Decorators Revisited

2012-08-13 Thread Jordi Boggiano
Heya, > What do you think? Is this a route that I should continue down? Or is there > something fundamental that I'm missing here? I know that Reflection, > get_interfaces(), etc would need to be updated to account for this. I can't speak for the feasibility, but from a usage point of view I do l

Re: [PHP-DEV] [RFC] Generators

2012-08-13 Thread Nikita Popov
On Sun, Aug 12, 2012 at 10:08 PM, Brian Moon wrote: > Also, not allowing rewinding is unintuitive for something that is an > iterator in PHP. If I can foreach() it and I can call next() on it, I expect > to be able to reset() it as well. IMO, you would need to issue a FATAL PHP > error if that sim

RE: [PHP-DEV] [RFC] Generators

2012-08-13 Thread Jared Williams
> -Original Message- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: 13 August 2012 03:49 > To: Brian Moon > Cc: Nikita Popov; PHP internals > Subject: Re: [PHP-DEV] [RFC] Generators > > Brian, > > On Sun, Aug 12, 2012 at 4:08 PM, Brian Moon > wrote: > > > Hi Nikita, >

[PHP-DEV] Re: [Voting] Call for voting for RFC: Supports finally keyword

2012-08-13 Thread Laruence
Hi all: after 1 week , we got the voting result: 25 supports, 5 against. here is the result: https://wiki.php.net/rfc/finally?&#changelog I am going to commit the patch to trunk. thanks for your great advise. :) thanks On Mon, Aug 6, 2012 at 7:39 PM, Laruence wrote: > Hi: >We have