Re: [RFC] Property hooks, nee accessors
| From: | Benjamin Außenhofer | 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
>
>