Re: [RFC] Property hooks, nee accessors

I can't wait! Especially because I'm heading a modernization of the systems in my organization and my plan is to use the cutting edge PHP version for it. Currently our internal "framework" uses PHP 7.4, but with a PHP 5.6 coding style. Again: I can't wait! I can't do much but thank everyone who spends their time to make PHP evolve.. Thank you all! Regards, Erick Em sex., 19 de mai. de 2023 às 17:48, Larry Garfield <larry@garfieldtech.com> escreveu: > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >