Re: [RFC] Property hooks, nee accessors

From: Date: Tue, 09 May 2023 12:38:56 +0000
Subject: Re: [RFC] Property hooks, nee accessors
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-120219@lists.php.net to get a copy of this message
On Mon, May 8, 2023 at 11:38 PM Larry Garfield <larry@garfieldtech.com> 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 Thank you! Looks interesting, I will need to think about things before more qualitative feedback. An error maybe, the "class C" example in "Detailed Proposal > set" uses a "$this->_prop", but probably meant to use $this->_names, since private array $_names; is declared in the example. I think $field should be its own "chapter". Its a central part of the proposal that should be clarified early and so that readers don't accidentally skip it. I am also confused why $field exists when $this->propertyName works and why its not recommended to be used. Is $field a reference? or does the "compile time macro" part mean its replaced at compile time? Ifso, this feels different to anything else PHP, i am leaning towards $this->propertyName if there are no other compelling reasons why $field should be used. > > > -- > Larry Garfield > larry@garfieldtech.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >

« previous php.internals (#120219) next »