Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124525
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-568-g843fbadbe-fm-20240701.003-g843fbadb
Precedence: bulk
MIME-Version: 1.0
Message-ID: <72182670-f9c2-4a6b-a124-6363140c06f3@app.fastmail.com>
In-Reply-To: 
 <CAPyj-LB6vLW+QBvu7XgbP_+=KOqYmYnuBkF56SzV9C7doAt3iw@mail.gmail.com>
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>
 <CAPyj-LB6vLW+QBvu7XgbP_+=KOqYmYnuBkF56SzV9C7doAt3iw@mail.gmail.com>
Date: Sat, 20 Jul 2024 16:45:56 -0500
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Jul 20, 2024, at 10:47 AM, Ilija Tovilo wrote:
> Hi Rob
>
> On Sat, Jul 20, 2024 at 3:47=E2=80=AFPM Rob Landers <rob@bottled.codes=
> wrote:
>>
>> 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, Ilij=
a realized that __set's behavior is already inconsistent, so supporting =
it for aviz properties with invisible set would make it even more incons=
istent, not less.  For that reason, we've changed the __set behavior suc=
h that a non-readonly aviz property will not trigger __set.  Further det=
ails are in the RFC, but in short, all of the use cases for that behavio=
r now have better alternatives, such as property types, hooks, and aviz =
itself.  So there's really no point to falling back to __set in edge cas=
es.
>>
>> https://wiki.php.net/rfc/asymmetric-visibility-v2#interaction_with_se=
t_and_unset

>> 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

After discussing with Ilija further, I've rewritten the __set section (a=
gain).  As Ilija said, the long and short of it is "we change nothing", =
but leave the door open to clean up __set's behavior in the future, once=
 we decide what cleanup is warranted.

--Larry Garfield