Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108567 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 11746 invoked from network); 14 Feb 2020 12:55:00 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 14 Feb 2020 12:55:00 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 7A2E61804AB for ; Fri, 14 Feb 2020 03:09:37 -0800 (PST) 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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (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 ; Fri, 14 Feb 2020 03:09:36 -0800 (PST) Received: by mail-io1-f50.google.com with SMTP id t26so10083651ioi.13 for ; Fri, 14 Feb 2020 03:09:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=PDF+VlRg/NDgXHFdHrFAXg7RZhVVVgTq3pMDO0ilKfE=; b=kiGCsb+xsNvNHk7+xf814hXRfO0pkGoM6MvP8UaK6NxWoCdGfgKWVjUByp5e1roUjG voJKffvAQb4p5et0fBAaiVoV3UpBXDe2jO96NDp4AoIA4uP84BICodmAbkRON1VhI8X/ bRvsRbQdMMk+kCkCgM0TbKZupV10UfDM6bXWpMQZLXVKztFnAVrw8MXvckN/ltQOnqVz qUyC8v7tEgOuH8JDzVe1DOc3yJVgsywu4ze4y3YMBP0nle9ZfCGY+TazlNLsIXv/0vA7 rOqjxpz3YpDNXFxACJza23S48ZqyoDTFfYaqow+61/MrPPsKKQkVbXD5G4jSRXPbZoAy tPQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=PDF+VlRg/NDgXHFdHrFAXg7RZhVVVgTq3pMDO0ilKfE=; b=AAZuQ59HVukgzpLuYr5JBNBEseczDSQV8m8+sq+rbSkFSkno2kH4iX7nH9zuAdHZga hmdXKWDxUMB1Bply9YM3LaVIzwobjPmYmAeSYCmRNVIb+wl3w2BbfE3xttvLrZKwjoAD sxOiP9KTO0VqCTt7SIBDDgrcRakduorzOHtLMLL5WuCLAHN79j0p/q+I4kpoYipodBCI GZ3Pb8rDPtXVZmqaP/mAlVizJ4z76cVweAcJt+UHpqy5P+mFmjMu0/5/EGD31afbg50+ Mzw0zsMKAhtXkcG2S8/8a+zARf6idhnvuQGvSgOlDxkOaDPqcArioi7i6Wim1L8ZOW3O bLSw== X-Gm-Message-State: APjAAAXWkapRXAqBWwRzUCVw7iWEHWMm8R3Xnq6K8n6JVoUK+kK6Aa9n 2Ye6mwGT//nF8R9yRtCiTUYGFed5kgOP9KIjH8+FI/54 X-Google-Smtp-Source: APXvYqxabHSTHMvPRgPTo3/8KSN255tb4v0TRqYtL3kO9B4D+H8b6S3+2K3p7c77lHX2RAtALieweDgOuIxUPiJWRXE= X-Received: by 2002:a05:6638:3f9:: with SMTP id s25mr2025161jaq.83.1581678574585; Fri, 14 Feb 2020 03:09:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 14 Feb 2020 11:09:23 +0000 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary="000000000000964bef059e873d7d" Subject: Re: [PHP-DEV] [Pre-RFC] Support for decorator patterns From: rowan.collins@gmail.com (Rowan Tommins) --000000000000964bef059e873d7d Content-Type: text/plain; charset="UTF-8" On Tue, 11 Feb 2020 at 10:14, Nikita Popov wrote: > I'd like to get some feedback on the idea implemented in > https://github.com/php/php-src/pull/5168. It provides an easy way to > implement decorates, by taking care of forwarding any methods you do not > want to override in a type-safe way. See the PR description for details. > Hi Nikita, I almost missed this thread because all the discussion has been happening off-list; for anyone else interested, please note that there's a whole discussion of the concept, not just the implementation, on the PR. I actually posted a similar idea a few months ago: https://externals.io/message/103353 One of the criticisms of my example syntax was that it required you to list the methods to delegate, which makes multiple delegates easier (you can't have a name conflict unless you write the name more than once), but large or frequently-changing targets unwieldy. The idea of using the property's interface type to generate the whitelist does feel a lot cleaner. The other criticism though was that it only helps for the methods you're completely delegating, not those you want to decorate in some way. It would be nice if there could also be some sugar for those, perhaps a limited form of AOP where you could intercept the return value of a delegated call? interface Bar { public function doSomething(int $a, string $b, Blob $c): string } class Foo implements Bar { public delegate Bar $bar; after delegate doSomething { return $return . ' of doom'; } } would de-sugar to: class Foo implements Bar { public Bar $bar; public function doSomething(int $a, string $b, Blob $c): string { $return = $this->bar->doSomething($a, $b, $c); return $return . ' of doom'; } } That would also cover the fluent interface case: after delegate setFoo { $this->delegated = $return; return $this; } Decorating what happens *before* the call would be trickier, because you need to assign names for the parameters, and by the time you've written out the whole signature, you might as well implement the method in full. Regards, -- Rowan Tommins [IMSoP] --000000000000964bef059e873d7d--