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 > > 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.
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
