Re: [RFC] Clone with v2
| From: | Nicolas Grekas | Date: | Fri, 16 May 2025 19:39:51 +0000 |
| Subject: | Re: [RFC] Clone with v2 | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-127390@lists.php.net to get a copy of this message | ||
Le jeu. 15 mai 2025 à 15:55, Tim Düsterhus <tim@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