Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97483
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain rochette.cc designates 62.210.206.189 as permitted sender)
To: Alexander Lisachenko <lisachenko.it@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <2aecc3f2-5e9d-907f-029b-5c60eb134b33@rochette.cc>
 <CAEbg-4amgYD_n2-WoD23AxEb8wRGitm951H-5BMMPo8aLF8z_w@mail.gmail.com>
Message-ID: <f9f32e31-bcba-10e8-11b3-868c63fe1bf3@rochette.cc>
Date: Thu, 29 Dec 2016 15:18:53 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101
 Thunderbird/51.0a2
MIME-Version: 1.0
In-Reply-To: <CAEbg-4amgYD_n2-WoD23AxEb8wRGitm951H-5BMMPo8aLF8z_w@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------4B0BEF5D21534DF2E9D1FDDE"
Content-Language: en-US
Subject: Re: [PHP-DEV] Decorator classes
From: mathieu@rochette.cc (Mathieu Rochette)

--------------4B0BEF5D21534DF2E9D1FDDE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit



On 29/12/2016 14:44, Alexander Lisachenko wrote:
>
> 2016-12-29 16:12 GMT+03:00 Mathieu Rochette <mathieu@rochette.cc 
> <mailto: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.
It is not class inheritance, as you can see in my example, the decorator 
is on an interface. one point of the decorator pattern is that you don't 
need to know
which class (or subclass) you are decorating. any object implementing 
the interface (or extending the class if it's a class you are 
decorating) can be decorated.

>
> 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)
>
I think PHP could be smart enough to do that too for non-decorated 
methods with the decorates keyword
>
>  1. 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)
>
I'm not sure decorator is appropriate here, in the article you are not 
decorating[1] your class; you are outsourcing the behavior but it's not 
the same
>
> 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/
>

[1] https://en.wikipedia.org/wiki/Decorator_pattern

--------------4B0BEF5D21534DF2E9D1FDDE--