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
