Re: [RFC] Asymmetric Visibility, v2

On Sat, Jul 20, 2024, at 10:47 AM, Ilija Tovilo wrote: > Hi Rob > > On Sat, Jul 20, 2024 at 3:47 PM 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, 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 >> 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 (again). 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