Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123062
Precedence: bulk
MIME-Version: 1.0
References: <CAPyj-LBMQEJ=2BF=xk_on4O2xTU+MM2XRAZ5g=uPwVOf=bh+sw@mail.gmail.com>
In-Reply-To: <CAPyj-LBMQEJ=2BF=xk_on4O2xTU+MM2XRAZ5g=uPwVOf=bh+sw@mail.gmail.com>
Date: Tue, 9 Apr 2024 10:07:34 -0600
Message-ID: <CAAKU0u=amT01bwyFdhhwvDR-X-_L39qFsOo2+4HoVZ4hBoV2NQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Vote announcement] Property hooks
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: levi.morrison@datadoghq.com (Levi Morrison)

On Mon, Apr 8, 2024 at 3:42=E2=80=AFPM Ilija Tovilo <tovilo.ilija@gmail.com=
> wrote:
>
> Hi everyone
>
> Heads-up: Larry and I would like to start the vote of the property
> hooks RFC tomorrow:
> https://wiki.php.net/rfc/property-hooks
>
> We have worked long and hard on this RFC, and hope that we have found
> some middle-ground that works for the majority. One last concern we
> have not officially clarified on the list:
>
> https://externals.io/message/122445#122667
>
> >> I personally do not feel strongly about whether asymmetric types make =
it into the initial implementation. Larry does, however, and I think it is =
not fair to exclude them without providing any concrete reasons not to. [sn=
ip]
> >
> > My concern is more about the external impact of what is effectively a c=
hange to the type system of the language: [snip] will tools like PhpStan an=
d Psalm require complex changes to analyse code using such properties?
>
> In particular, this paragraph is referencing the ability to widen the
> accepted $value parameter type of the set hook, described at the
> bottom of https://wiki.php.net/rfc/property-hooks#set. I have talked
> to Ond=C5=99ej Mirtes, the maintainer of PHPStan, and he confirmed that
> this should not be complex to implement in PHPStan. In fact, PHPStan
> already offers the @property-read and @property-write class
> annotations, which can be used to describe "virtual" properties
> handled within __get/__set, already providing asymmetric types of
> sorts. Hence, this concern should be a non-issue.
>
> Thank you to everybody who has contributed to the discussion!
>
> Ilija

I was playing around with 3v4l.org. Is the implementation up-to-date there?

I don't have any hard objections at the moment, but after playing with
it for a while, I do kind of wonder if it's a lot of complexity for
what is effectively a niche feature because:

 1. It does not support asymmetric visibility for get/set. Having a
public getter and private setter seems really natural.
 2. You can't access accessors for "siblings".
 3. You can't do by-reference set (important for arrays).
 4. You can't satisfy a parent's readonly property with a getter in a child=
.

Now, points 2 through 4 are fairly minor and niche by themselves, but
if we take all these restrictions as a whole... I'm a bit worried.

I also don't like the syntax. I can ignore this for the vote and still
vote yes because I don't like the syntax, but with these other
things... I'm worried.