Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127377
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 15 May 2025 15:53:46 +0200
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Clone with v2
In-Reply-To: <b1bef725-5c17-47c4-8019-7f3135a5a682@app.fastmail.com>
References: <CAMzRQTdePFXUMWO38g=gQA2vbqL5zp=o1cPt00ec41g95xys=g@mail.gmail.com>
 <CAJp_myXREmnyufwxj4tDCsopouUFEWenap5EJaH+sXKTyg4K1Q@mail.gmail.com>
 <4a703db4174763586d84b9bf5606ff31@bastelstu.be>
 <b1bef725-5c17-47c4-8019-7f3135a5a682@app.fastmail.com>
Message-ID: <956887e5b66e2b43459b999ebac2069d@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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