Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124517
Precedence: bulk
MIME-Version: 1.0
References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com>
 <b5c0be62-ea39-47fb-a8f8-ab6cd5ee3dab@app.fastmail.com> <284c6693-d9bf-4495-adc1-3cc8d5e54ee5@app.fastmail.com>
In-Reply-To: <284c6693-d9bf-4495-adc1-3cc8d5e54ee5@app.fastmail.com>
Date: Sat, 20 Jul 2024 17:47:05 +0200
Message-ID: <CAPyj-LB6vLW+QBvu7XgbP_+=KOqYmYnuBkF56SzV9C7doAt3iw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2
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 Rob

On Sat, Jul 20, 2024 at 3:47=E2=80=AFPM Rob Landers <rob@bottled.codes> wro=
te:
>
> On Sat, Jul 20, 2024, at 03:14, Larry Garfield wrote:
>
> On Wed, May 29, 2024, at 2:15 PM, Larry Garfield wrote:
> >
> > https://wiki.php.net/rfc/asymmetric-visibility-v2
>
> Hi folks.  After a side quest to polish off hooks, we're nearly ready to =
bring aviz to a vote.
>
> We've made one change since we last discussed it:  Specifically, Ilija re=
alized that __set's behavior is already inconsistent, so supporting it for =
aviz properties with invisible set would make it even more inconsistent, no=
t less.  For that reason, we've changed the __set behavior such that a non-=
readonly aviz property will not trigger __set.  Further details are in the =
RFC, but in short, all of the use cases for that behavior now have better a=
lternatives, such as property types, hooks, and aviz itself.  So there's re=
ally no point to falling back to __set in edge cases.
>
> https://wiki.php.net/rfc/asymmetric-visibility-v2#interaction_with_set_an=
d_unset
>
> Hmm,
>
> There=E2=80=99s a lot of existing code that relies on this behavior, it=
=E2=80=99s pretty much the best way to create proxies without requiring cod=
e generation.
>
> This is a pretty massive breaking change.

There was a miscommunication between Larry and me. The change is not
to any existing behavior. __get/__set are currently called under two
circumstances:

* The properties _full_ visibility is not met.
* The property was explicitly unset.

We're not changing this behavior. Instead, we decided not calling
__set for asymmetric visibility, when only the set visibility isn't
met. Before making this decision, implicitly implying protected(set)
for a readonly property would have led to __set being called (because
the scope protection now comes from asymmetric visibility, rather than
readonly itself), which would have been a change to the current
behavior.

So, in short: If only the set visibility isn't met, we're now throwing
an error. This is consistent with readonly today, and with get-only
hooks. If somebody wants to change this in the future, they can do so
without any BC breaks, and most likely should make the behavior
consistent across all of these three cases.

Ilija