On Sat, Jul 20, 2024, at 03:14, Larry Garfield wrote:
> 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
>
Hmm,
There’s a lot of existing code that relies on this behavior, it’s pretty much the best way to
create proxies without requiring code generation.
This is a pretty massive breaking change.
— Rob