Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124508
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: <b5c0be62-ea39-47fb-a8f8-ab6cd5ee3dab@app.fastmail.com>
In-Reply-To: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com>
References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com>
Date: Fri, 19 Jul 2024 20:14:49 -0500
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, May 29, 2024, at 2:15 PM, Larry Garfield wrote:
> As promised, Ilija and I offer this revised version of asymmetric visibility.  
>
> https://wiki.php.net/rfc/asymmetric-visibility-v2
>
> It's still essentially the same as last year's version, but with a few 
> adjustments and changes:
>
> * readonly properties are now supported in a logical fashion.
> * We've brought back the abbreviated form, as public-read, something 
> else set is the most common use case.
> * The section on magic methods has been greatly simplified.  The 
> implementation itself hasn't changed, but the explanation is a lot less 
> confusing now.
> * We've explained how aviz interacts with hooks (they don't, really) 
> and with interface properties (in the obvious way), which didn't exist 
> at the time of the last draft.
> * We've added a section with examples of how aviz is a concrete 
> improvement, even in a world with readonly and hooks.
> * We've added a section discussing why the prefix-style syntax was 
> chosen.

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 realized that __set's behavior is already inconsistent, so supporting it for aviz properties with invisible set would make it even more inconsistent, not 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 alternatives, such as property types, hooks, and aviz itself.  So there's really no point to falling back to __set in edge cases.

https://wiki.php.net/rfc/asymmetric-visibility-v2#interaction_with_set_and_unset

Baring any new developments, we plan to start the vote early next week.

Cheers.

--Larry Garfield