Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97485
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: Marco Pivetta <ocramius@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <2aecc3f2-5e9d-907f-029b-5c60eb134b33@rochette.cc>
 <CADyq6sJ81NxA=DbRVJQfX8omyzBMew=TXZDdsPUDD52pwVt2+w@mail.gmail.com>
Message-ID: <4a5e4cd4-9414-ebef-d5a7-739bb4df34dd@rochette.cc>
Date: Thu, 29 Dec 2016 15:27:30 +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: <CADyq6sJ81NxA=DbRVJQfX8omyzBMew=TXZDdsPUDD52pwVt2+w@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------A438F83A6F43CE7D3559595B"
Content-Language: en-US
Subject: Re: [PHP-DEV] Decorator classes
From: mathieu@rochette.cc (Mathieu Rochette)

--------------A438F83A6F43CE7D3559595B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit



On 29/12/2016 14:18, Marco Pivetta wrote:
>
> On Thu, Dec 29, 2016 at 2:12 PM, Mathieu Rochette <mathieu@rochette.cc 
> <mailto:mathieu@rochette.cc>> wrote:
>
>     Hello internals,
>
>     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:
>
>     interface Foo {
>       public bar();
>       public taz();
>     }
>
>     class EchoFooBar decorates Foo {
>       public function bar() {
>         $this->logger->debug("foo bar");
>         return $this->decorated->bar();
>       }
>     }
>
>     class LoggedFooTaz decorates Foo {
>       private $logger;
>
>       public function __construct(Foo $decorated, Logger $logger) {
>         $this->logger = $logger;
>         $this->decorated = $decorated;
>       }
>
>       public function taz() {
>         $this->logger->debug("foo taz");
>         return $this->decorated->taz();
>       }
>     }
>
>     * 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 ?
>
>
>     thank you
>
>
>     [1] https://dzone.com/articles/is-inheritance-dead
>     <https://dzone.com/articles/is-inheritance-dead>
>
>     -- 
>     PHP Internals - PHP Runtime Development Mailing List
>     To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> Just my 2 cents:
>
> Too much magic syntactic sugar, whereas you are just saving very 
> little time while implementing a few method stubs that take..
yeah it's mostly syntactic sugar, I think it would encourage developer 
to use this pattern instead of inheritance when appropriate.
I also think that most of the time using the decorator pattern helps 
following the single responsibility principle

also, this would add one more benefit : methods that are not override 
could probably be optimized by the PHP engine (avoid one userland proxy 
call)
>
> Yet, in order to achieve that, you added a huge amount of complexity 
> for all the tooling that  relies on the AST, including PHP itself.
> .
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>


--------------A438F83A6F43CE7D3559595B--