Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62134
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAJDSdj3D6YGfAnsz9qVDg6buCFi5ukZdZvfgauFAeejuYxSzFQ@mail.gmail.com>
References: <CAAyV7nEZdNbWht+8Fy4ZpS=AjkzYq4Yk7XhJWV3sSV_NpgVS2g@mail.gmail.com>
	<50298AC9.4070302@naderman.de>
	<CAJDSdj3D6YGfAnsz9qVDg6buCFi5ukZdZvfgauFAeejuYxSzFQ@mail.gmail.com>
Date: Mon, 13 Aug 2012 20:16:19 -0400
Message-ID: <CAAyV7nGeVvnXquHTncvhEn45mds++kOh+qr6eFf3N0fhLzHxyw@mail.gmail.com>
To: Nicholas Curtis <nich.curtis@gmail.com>
Cc: Nils Adermann <naderman@naderman.de>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf303640cf33761604c72eb8cd
Subject: Re: [PHP-DEV] Decorators Revisited
From: ircmaxell@gmail.com (Anthony Ferrara)

--20cf303640cf33761604c72eb8cd
Content-Type: text/plain; charset=ISO-8859-1

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.curtis@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 <naderman@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
> >
> >
>

--20cf303640cf33761604c72eb8cd--