Le jeu. 15 mai 2025 à 15:55, Tim Düsterhus <t...@bastelstu.be> a écrit :
> 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. > > Being able to update a readonly property even if __clone already touched it looks critical to me because otherwise, it'd mean that adding a __clone method after publishing a first version of some class that has no __clone method would be a BC break. Nicolas
