Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119004
MIME-Version: 1.0
References: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com>
 <D372FB9F-10CF-45D0-923F-6DD04A4BC76E@koalephant.com> <alpine.DEB.2.23.453.2211141130260.1167818@singlemalt.home.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.23.453.2211141130260.1167818@singlemalt.home.derickrethans.nl>
Date: Mon, 14 Nov 2022 13:00:23 +0100
Message-ID: <CAPyj-LB9diYUDL1oz2i0j6fz8epiMsvM-RvXt59pP=sSdqzkXg@mail.gmail.com>
To: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
From: tovilo.ilija@gmail.com (Ilija Tovilo)

Hi Derick

> > As I understand it, you=E2=80=99re suggesting that a property declared =
as
> > `public protected(set)` would never trigger __set().
>
> I would think that that would be against our current practice, which is
> easy enough to explain as "if the property isn't visible set,
> then use __set()". I would argue that "protected(set)" marks a property
> as invisible from a non-inherited class/method, and hence __set should
> be called.

What you're describing does not match the readonly behavior.
https://3v4l.org/X76pV

Readonly properties only call __set once they are explicitly unset.
The same applies to __unset. I changed this in the asymmetric
visibility implementation recently to match this behavior but the RFC
has not been adjusted to reflect this yet.

AFAIK this behavior is there to allow calls to __set for certain edge
cases. While not very intuitive it makes sense to stay consistent. If
this behavior is undesirable we should change it in both places.

Ilija