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

Reply via email to