Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:120362 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 59595 invoked from network); 19 May 2023 20:48:14 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 19 May 2023 20:48:14 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D6D7B1804F7 for ; Fri, 19 May 2023 13:48:11 -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.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS29838 64.147.123.0/24 X-Spam-Virus: No X-Envelope-From: Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 19 May 2023 13:48:11 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 7FA9B3200976 for ; Fri, 19 May 2023 16:48:08 -0400 (EDT) Received: from imap50 ([10.202.2.100]) by compute4.internal (MEProxy); Fri, 19 May 2023 16:48:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= garfieldtech.com; h=cc:content-type:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1684529288; x= 1684615688; bh=XgTvKZcUOjimoaTQsPuLLF2Fyq44yuEX+veSPw9KOOA=; b=I R8HC7yVpCl6np/Rm6csqdsODRZ95vLyo+FUBiEa1CiEHyVkzGewrlg2NiDWhpix4 l0b7I+wMcCcbilGNSH9vkU887PDVgl0KfMiXKs0XSbZNegVMKrfgjHhAREZQ3W+n 1mvpOwcJP7X0QZ5JeuXymzy5ZhuxxN6yWWptQ6FNBvDs5QKynmpcYAu4NNT73rko umDldz/2fsselWYgkJd9nlqYLGjzWpqxzjWmhTnftiBoB2U+sAz5d/9UdUcj9Brs IqizA2ncu7VUlHk9ktR8vIjOYZceq48aX+8RX7JGmdHYgjjwtdZuGFCMyVk/3VUR yeVJsQIrmv4PFyUSFceGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1684529288; x=1684615688; bh=XgTvKZcUOjimo aTQsPuLLF2Fyq44yuEX+veSPw9KOOA=; b=kPAcQjl5bmwu90FbNpTvgy2W40+S5 zEu/Ay+6+gkHc4YltczTgvwGKCt85bSp7kARwaH3R+LSWmcNpgh94mGg0HFPo9vZ RhtT2I8Ow5iPJooyC8Vvp0mLKTeKhn3Ytr44F5pUNyjzj0L0k0QoNBEATHc+zUZY teGlEe1x4Npr3xGDBZINDrr5kj34YRQZCYknojswyR+/HgE7mjmEdgLzHSbfQIbv Jf0SZkTVy2PutlobH9ygKjWo8HGd+9JEdvIh80TrqcwPyflPaeM37N1fDMqbRBmY 27i2QZ6WgjfywwuHshRNa6i+AlB59C4hZcplgRZtvVNTH63Khjc6KRw8g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeeihedgudehfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfnfgr rhhrhicuifgrrhhfihgvlhgufdcuoehlrghrrhihsehgrghrfhhivghlughtvggthhdrtg homheqnecuggftrfgrthhtvghrnhepveehhedvveejledvvefgleevffdtjeekledvkeeg heffgfeivdejhffhledtudetnecuffhomhgrihhnpehphhhprdhnvghtnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheplhgrrhhrhiesghgrrhhf ihgvlhguthgvtghhrdgtohhm X-ME-Proxy: Feedback-ID: i8414410d:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id CAA5B1700089; Fri, 19 May 2023 16:48:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-431-g1d6a3ebb56-fm-20230511.001-g1d6a3ebb Mime-Version: 1.0 Message-ID: <6b1fe5c4-fa92-42c0-b388-32cdda0a27a2@app.fastmail.com> In-Reply-To: <641b1ca0-d33f-4f38-ae64-81b4abce24da@app.fastmail.com> References: <641b1ca0-d33f-4f38-ae64-81b4abce24da@app.fastmail.com> Date: Fri, 19 May 2023 20:47:15 +0000 To: "php internals" Content-Type: text/plain Subject: Re: [PHP-DEV] [RFC] Property hooks, nee accessors From: larry@garfieldtech.com ("Larry Garfield") On Mon, May 8, 2023, at 9:38 PM, Larry Garfield wrote: > Ilija Tovilo and I would like to offer another RFC for your > consideration. It's been a while in coming, and we've evolved the > design quite a bit just in the last week so if you saw an earlier draft > of it in the past few months, I would encourage you to read it over > again to make sure we're all on the same page. I'm actually pretty > happy with where it ended up, even if it's not the original design. > This approach eliminates several hard-to-implement edge cases while > still providing a lot of functionality in one package. > > https://wiki.php.net/rfc/property-hooks Hi folks. Based on feedback we've made a few smaller changes to the RFC. Changelog: * The sections describing isset/unset and magic methods have been rewritten to be clearer. Nothing changed in the actual behavior, it is now just explained better. * Contravariance on the "set" type is now enforced. Ilija figured out how to make it work. :-) That means a non-contravariant type on the set hook will now throw an error, as expected. * After extensive discussion with Nicolas Grekas, we've decided to allow references in a very narrow case. Specifically, on a *virtual property* (one that has no inherent backing store), you may implement a `&get` hook instead of `get`, and the value it returns will be returned by reference, and may be captured using $foo =& $bar->baz; We determined that it is a bit better for BC (in the rare cases that you actually want to get a reference to a property, you can, even if it requires a little more work), doesn't break anything else, and is consistent with the way `&__get` behaves. __get/__set are basically "anonymous virtual properties", so now they behave the same way. By the same token, setting by reference is still not allowed, which is also true for __set today. As there was no other interest in it stated, we're going to hold off on an `unset` hook at this time. Given the earlier discussion I think there is a valid use case for it, so it would be a worthwhile follow up RFC in the future, but for the moment we want to keep it simple. There also doesn't seem to be much interest in specifying which hook gets the double-shortened syntax. I can see the argument for it, but it would increase the typing in a common case for an unclear benefit, and only one person expressed any interest in it. So we're not going to go that route. There's two items still pending. 1. Ilija is experimenting with the `parent::$prop::get()` syntax, to see if either the syntax or implementation can be simplified. There may or may not be a small change here as a result, TBD. 2. Ilija still has to verify that foreach() can work with virtual properties as the RFC currently describes. The implementation details are thornier than they seem, so that still needs some validation and testing. Assuming both of those get sorted out soon, we will probably call a vote around the end of the month, give or take. Cheers. --Larry Garfield