On Thu, May 15, 2025, at 8:53 AM, Tim Düsterhus wrote:
> Hi
>
> Am 2025-05-15 00:04, schrieb Larry Garfield:
>> Subtle point here. If the __clone() method touches a readonly
>> property, does that make the property inaccessible to the new
>> clone-with?
>
> Yes. Quoting from the RFC:
>
>> The currently linked implementation “locks” a property if it modified
>> within __clone(), if this is useful is up for debate.
>
> -
>
>> A single unlock block would be confusing to me.
>
> We’ve implemented it like that, because it felt most in line with what
> was decided in
> https://wiki.php.net/rfc/readonly_amendments#proposal_2readonly_properties_can_be_reinitialized_during_cloning,
>
> which says:
>
>> Reinitialization of each property is possible once and only once:
>
> We expect “public(set) readonly” + “__clone()” to be rare and from
> within the class, the author knows how their __clone() implementation
> works and can make sure it is compatible with whatever properties they
> might want to update during cloning. The lack of “use cases” is the
> primary reason we made the more conservative choice, but we are not
> particularly attached to this specific behavior.
>
> Best regards
> Tim Düsterhus
Fair. I could probably think of a use case if I tried hard, but I can't think of one off hand.
It's just surprising in the abstract. I suppose making it a single unlock scope leaves open
the option to split it in two later, but the reverse is not true. I won't fight for this one,
just noting it as surprising.
--Larry Garfield