Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97482
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <2aecc3f2-5e9d-907f-029b-5c60eb134b33@rochette.cc>
References: <2aecc3f2-5e9d-907f-029b-5c60eb134b33@rochette.cc>
Date: Thu, 29 Dec 2016 16:44:19 +0300
Message-ID: <CAEbg-4amgYD_n2-WoD23AxEb8wRGitm951H-5BMMPo8aLF8z_w@mail.gmail.com>
To: Mathieu Rochette <mathieu@rochette.cc>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11427400481c720544cc4858
Subject: Re: [PHP-DEV] Decorator classes
From: lisachenko.it@gmail.com (Alexander Lisachenko)

--001a11427400481c720544cc4858
Content-Type: text/plain; charset=UTF-8

2016-12-29 16:12 GMT+03:00 Mathieu Rochette <mathieu@rochette.cc>:

> I find that using the decorator pattern is very verbose and maybe
> something could be done about that,
> an article[1] I saw proposed a "decorates" keyword to solves this, here is
> how it might look like in PHP:
>


> * the constructor is optional and default to take the first argument and
> put it in $decorated
> * if the constructor is provided PHP check that $decorated is set and
> implements the decorated interface or class
> * all public methods not overridden are automatically proxied to the
> decorated object
>
> There is at least a few different ways to go about this, the previous
> example was just to give you a preview of what it could be. If there is
> interest I'd like to write an RFC for this :)
>
> What do you think about this ?
>

Hi! I think that language doesn't need any additional keywords for that.
What you describe is pure class inheritance and it's already available in
the language.

To be honest I use class inheritance in Go! AOP to define decorators
because of some nice features:

   1. No overhead for calling non-decorated method (we can wrap only
   required methods)
   2. Only one single instance of class, whereas traditional proxy and
   decorator pattern will use two instances (one for the original instance
   itself and one more instance for proxy/decorator)

What your want can be implemented with the help of one single aspect,
applied to your codebase. Then framework will automatically create
decorators for every required class in your system. For logging decorator
example see my blogpost here:
http://go.aopphp.com/blog/2013/07/21/implementing-logging-aspect-with-doctrine-annotations/

--001a11427400481c720544cc4858--