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

Reply via email to