Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122450
Precedence: bulk
MIME-Version: 1.0
References: <fca97d6c-d4ec-4000-958a-72c32beb8421@app.fastmail.com> <c78fd6f6-548d-409f-8125-eabcb35f0687@processus.org>
In-Reply-To: <c78fd6f6-548d-409f-8125-eabcb35f0687@processus.org>
Date: Thu, 22 Feb 2024 02:14:32 +0100
Message-ID: <CAPzBOBNMDfDdTNDoUx4cBOyqyAKGVW0wcP5xVETVc+sHgDFdsg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2
To: Pierre <pierre-php@processus.org>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Thu, Feb 22, 2024 at 1:03=E2=80=AFAM Pierre <pierre-php@processus.org> w=
rote:
>
> Le 21/02/2024 =C3=A0 19:55, Larry Garfield a =C3=A9crit :
> > Hello again, fine Internalians.
> >
> > After much on-again/off-again work, Ilija and I are back with a more po=
lished property access hooks/interface properties RFC.  It=E2=80=99s 99% un=
changed from last summer; the PR is now essentially complete and more robus=
t, and we were able to squish the last remaining edge cases.
> >
> > Baring any major changes, we plan to bring this to a vote in mid-March.
> >
> > https://wiki.php.net/rfc/property-hooks
> >
> > It=E2=80=99s long, but that=E2=80=99s because we=E2=80=99re handling ev=
ery edge case we could think of.  Properties involve dealing with both refe=
rences and inheritance, both of which have complex implications.  We believ=
e we=E2=80=99ve identified the most logical handling for all cases, though.
> >
> > Note the FAQ question at the end, which explains some design choices.
> >
> > There=E2=80=99s one outstanding question, which is slightly painful to =
ask: Originally, this RFC was called =E2=80=9Cproperty accessors,=E2=80=9D =
which is the terminology used by most languages.  During early development,=
 when we had 4 accessors like Swift, we changed the name to =E2=80=9Chooks=
=E2=80=9D to better indicate that one was =E2=80=9Chooking into=E2=80=9D th=
e property lifecycle.  However, later refinement brought it back down to 2 =
operations, get and set.  That makes the =E2=80=9Chooks=E2=80=9D name less =
applicable, and inconsistent with what other languages call it.
> >
> > However, changing it back at this point would be a non-small amount of =
grunt work. There would be no functional changes from doing so, but it=E2=
=80=99s lots of renaming things both in the PR and the RFC. We are willing =
to do so if the consensus is that it would be beneficial, but want to ask b=
efore putting in the effort.
> >
> Yes please ! Pass !
>
> I don't have voting rights, but we need this.
>
> Cheers,
>
> Pierre R.

I apologize if this has already been covered:

> There are two shorthand notations supported, beyond the optional argument=
 to set.
> First, if a hook's body is a single expression, then the { } and return s=
tatement may be omitted and replaced with =3D>, just like with arrow functi=
ons.

Does =3D> do any special auto-capturing of variables like arrow
functions or is it just a shorthand? Also, is this a meaningful
shorthand to the example a little further down:

public string $phone {
    set =3D $this->sanitizePhone(...);
}

or do we always have to write it out?

public string $phone {
    set =3D> $field =3D $this->sanitizePhone($value);
}

Would __PROPERTY__ be set inside sanitizePhone() as well?

You mention several ways values are displayed (whether or not they use
the get-hook), but what does the default implementation of
`__debugInfo()` look like now (or is that out of scope or a silly
question?)

For attributes, it would be nice to be able to target hooks
specifically with attributes instead of also all methods (e.g., a
Attribute::TARGET_GET_HOOK const). For example, if I were writing a
serialization library, I may want to specify #[UseRawValue] only on
getters to ensure that only the raw value is serialized instead of the
getter (which may be specific to the application logic, or
#[GetFromMethod] to tell the serialization library to get the value
from a completely different method. It wouldn't make sense to target
just any method with that attribute.