Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:113523 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 74035 invoked from network); 14 Mar 2021 22:15:03 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Mar 2021 22:15:03 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DE6671804B8 for ; Sun, 14 Mar 2021 15:08:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from wp160.webpack.hosteurope.de (wp160.webpack.hosteurope.de [80.237.132.167]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sun, 14 Mar 2021 15:08:24 -0700 (PDT) Received: from [2a02:8109:9d40:1d44:40b6:f5d3:c567:d46c] (helo=nas.fritz.box); authenticated by wp160.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1lLYuN-0000tE-MU; Sun, 14 Mar 2021 23:08:23 +0100 To: internals@lists.php.net References: Message-ID: <10fcf0a0-fe32-731c-1b1c-2a802379d189@mabe.berlin> Date: Sun, 14 Mar 2021 23:08:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-bounce-key: webpack.hosteurope.de;marc@mabe.berlin;1615759704;c7c667dd; X-HE-SMSGID: 1lLYuN-0000tE-MU Subject: Re: [PHP-DEV] Built-in decorator attribute? From: marc@mabe.berlin (Marc) On 14.03.21 12:52, Benjamin Eberlei wrote: > On Sat, Mar 13, 2021 at 5:51 PM David Gebler wrote: > >> With the introduction of attributes in PHP 8, this new behaviour is still >> quite sparsely documented. Some of the articles I've seen out there, >> though, liken PHP's attributes to similar constructs in other languages >> including decorators in Python. >> >> Attributes are not the same thing as (Python's concept of) decorators and >> they shouldn't be confused; a decorator is a function which wraps another >> function and is automatically called in place of the wrapped function. >> >> This isn't currently possible in PHP. Using frameworks like Symfony, we can >> start to build things like this: >> >> class UserProfileController { >> #[LoginRequired] >> public function editProfile(...) { } >> } >> >> but the logic of enforcing our "require the user to be logged in" decorator >> relies on the surrounding framework controlling the flow of execution, >> reading the attribute and deciding whether to call the decorated method >> editProfile() at all. >> >> What we *can't* do is something like this: >> >> class Foo { >> private function timer(callable $wrapped) >> { >> $start = microtime(true); >> $wrapped(); >> $end = microtime(true); >> $total = $end - $start; >> echo "Executed function in $total second(s)\n"; >> } >> >> #[timer] >> public function bar($a, $b) { ... } >> >> #[timer] >> public function baz($a, $b) { ... } >> } >> >> What I'm wondering is whether there's a desire / interest for a built-in >> attribute to provide this kind of behaviour modification. >> >> I'm thinking something like >> >> class Foo { >> private function timer(callable $wrapped) { ... } >> >> #[Decorator([self::class, 'timer'])] >> public function bar() { >> echo "Bar"; >> } >> } >> >> Where this would result in any call to $foo->bar() being equivalent to as >> if the above were defined as: >> >> class Foo { >> private function timer(callable $wrapped) { ... } >> >> public function __bar() { >> echo "Bar"; >> } >> >> public function bar() { >> return $this->timer([$this, '__bar']); >> } >> } >> >> I'm not saying I have the skills to implement this attribute (though I'd >> happily try), I'm not even in a position to propose a draft RFC at this >> stage, just throwing the idea out there to get a feel for what people think >> of the concept? >> > In my opinion it would be a fantastic addition to Core to be used by > application frameworks with "hook philosophies" that hack this > functionality on top of PHP with code generation or event dispatchers at > the moment (Magento 2, Drupal, Neos, Wordpress and so on) makes this a > potential future with wide adoption. If you'd get 2/3 votes for it is > another topic. I can fully agree here - this would be very useful and I also thought in trying out something similar to wrap expensive functions by a cache but I don't have enough C skills and even less time for that. Thanks, Marc