Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123073
Precedence: bulk
MIME-Version: 1.0
References: <CAPyj-LBMQEJ=2BF=xk_on4O2xTU+MM2XRAZ5g=uPwVOf=bh+sw@mail.gmail.com>
 <CAAKU0u=amT01bwyFdhhwvDR-X-_L39qFsOo2+4HoVZ4hBoV2NQ@mail.gmail.com>
 <9ff3864e-7fb8-4ad1-bbd7-f8c69567a34d@app.fastmail.com> <CAPzBOBPaGtUMJrEv60BpGBnka2KoZh22KhafkrOHP4G=QM6nGg@mail.gmail.com>
In-Reply-To: <CAPzBOBPaGtUMJrEv60BpGBnka2KoZh22KhafkrOHP4G=QM6nGg@mail.gmail.com>
Date: Tue, 9 Apr 2024 22:37:26 +0200
Message-ID: <CAPyj-LBnxy2QCy-OvzvAti5d7gXc84HauSc_k71Nx=uGV45evw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Vote announcement] Property hooks
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Robert

On Tue, Apr 9, 2024 at 9:34=E2=80=AFPM Robert Landers <landers.robert@gmail=
.com> wrote:
>
> On Tue, Apr 9, 2024 at 8:56=E2=80=AFPM Larry Garfield <larry@garfieldtech=
.com> wrote:
> >
> > The Aviz RFC was put to a vote last year but didn't pass.
>
> It would be really nice if votes weren't just a yes/no vote, but
> yes/needs-more-work/no vote, where needs-more-work and no are
> effectively the same in terms of passing the RFC, but needs-more-work
> just means there is more to do (either addressing ugly syntax or the
> idea is sound, but as it says, it needs more work), and can thus be
> simply revoted on after concerns are addressed -- instead of creating
> a whole new RFC that needs to pass the "not too similar to other RFCs
> rule."

The asymmetric visibility RFC did include a poll for no votes.
https://wiki.php.net/rfc/asymmetric-visibility#proposed_voting_choices

> I got the impression from the Aviz discussions that most people were
> against Aviz due to the syntax, not the feature itself. It would be
> absolutely tragic if this failed to pass simply because people
> expected Aviz here.

According to the poll, syntax was one, but not the primary reason for
its rejection. The primary reason was that some people don't believe
the feature is necessary at all.

IIRC, people were arguing that readonly covers 80% of use-cases,
because it protects against writes to the property both publicly and
privately. I don't agree with this viewpoint, because I think readonly
is bad for ergonomics. In fact, we already had an RFC that attempted
to fix clone for readonly
(https://wiki.php.net/rfc/readonly_amendments) but this fix was not
complete (because it's still not possible to pass values from clone to
__clone). "Clone with" is another thing needed to fix this, and at
this point it just feels like applying more band-aids.

For DTOs, I believe value types (i.e. data classes,
https://externals.io/message/122845) solve the problem of "spooky
actions at a distance" in a cleaner and more ergonomic way.

For services and other intentional reference types, readonly often
isn't the right choice either, just to make the property not publicly
writable. Asymmetric visibility would be a much more fitting choice.

Anyway, we didn't include asymmetric visibility in this RFC because:

* We wanted to avoid getting rejected by people who fundamentally
dislike asymmetric visibility.
* We didn't feel it was fair to "sneak" the feature back in through
some other RFC, when it was explicitly rejected.

Instead, we are planning to re-propose asymmetric visibility once
property hooks are merged, as it may become more apparent why it is
useful.

Ilija