Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120267
MIME-Version: 1.0
References: <641b1ca0-d33f-4f38-ae64-81b4abce24da@app.fastmail.com> <57aed5a4-f5e5-4a47-bf7a-69249f1d0ef1@app.fastmail.com>
In-Reply-To: <57aed5a4-f5e5-4a47-bf7a-69249f1d0ef1@app.fastmail.com>
Date: Sat, 13 May 2023 22:52:57 -0400
Message-ID: <CAKuGYLSXdhEuLoy19Yw5WgP13OA5hVXPtT=h35jww0BeOJJdUQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000032bf6e05fb9e7083"
Subject: Re: [PHP-DEV] [RFC] Property hooks, nee accessors
From: matthewmatthew@gmail.com (Matthew Brown)

--00000000000032bf6e05fb9e7083
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> Regarding $field vs. $this->propName, there's a few reasons we went that
> route.


Overall I think this is a really good proposal, but you might want to
consider a second vote for that particular syntax.

`$field` vs `$this->propName` feels a little magical. It's a simpler magic
than actual magic methods =E2=80=94 it's magic that static analysis tools c=
an
quickly reason about (as they can with promoted properties).

But I can imagine developers coming across this particular syntax in a PR
and thinking "that looks like a bug".

I know it's a few extra keypresses, but I think $this->propName is easier
to scan, and more familiar (given this RFC introduces a lot of other new
syntax).

--00000000000032bf6e05fb9e7083--