Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127378
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 15 May 2025 09:03:07 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <bca6d562-6e31-4908-a01b-fb524f226029@app.fastmail.com>
In-Reply-To: <F38892E6-4219-4B1A-A2C5-4F06AE70056F@koalephant.com>
References: 
 <CAMzRQTdePFXUMWO38g=gQA2vbqL5zp=o1cPt00ec41g95xys=g@mail.gmail.com>
 <CAJp_myXREmnyufwxj4tDCsopouUFEWenap5EJaH+sXKTyg4K1Q@mail.gmail.com>
 <CAMzRQTfWj=CFsu=OyOiK_HiwCM5UkyPhfY3DiwSBF4N3FtzObA@mail.gmail.com>
 <F38892E6-4219-4B1A-A2C5-4F06AE70056F@koalephant.com>
Subject: Re: [PHP-DEV] [RFC] Clone with v2
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, May 15, 2025, at 1:22 AM, Stephen Reay wrote:

> I may be missing something here.. 
>
> So far the issues are "how do we deal with a parameter for the actual 
> object, vs new properties to apply",  "should __clone be called before 
> or after the changes" and "this won't allow regular readonly properties 
> to be modified".
>
> Isn't the previous suggestion of passing the new property arguments 
> directly to the __clone method the obvious solution to all three 
> problems? 
>
> There's no potential for a conflicting property name, the developer can 
> use the new property values in the order they see fit relative to the 
> logic in the __clone call, and it's inherently in scope to write to any 
> (unlocked during __clone) readonly properties.

I did some exploratory design a few years ago on this front, looking at the implications of different possible syntaxes.

https://peakd.com/hive-168588/@crell/object-properties-part-2-examples

What that article calls "initonly" is essentially what became readonly.  The second example is roughly what this RFC would look like if the extra arguments were passed to __clone().  As noted in the article, the result is absolutely awful.

Auto-setting the values while using the clone($object, ...$args) syntax is the cleanest solution.  Given that experimentation, I would not support an implementation that passes args to __clone and makes the developer figure it out.  That just makes a mess.

Rob makes a good point elsewhere in thread that running __clone() afterward is a way to allow the object to re-inforce validation if necessary.  My concern is whether the method knows it needs to do the extra validation or not, since it may be arbitrarily complex.  It would also leave no way to reject the changes other than throwing an exception, though in fairness the same is true of set hooks.  Which also begs the question of whether a set hook would be sufficient that __clone() doesn't need to do extra validation?  At least in the typical case?

One possibility (just brainstorming) would be to update first, then call __clone(), but give clone a new optional arg that just tells it what properties were modified by the clone call.  It can then recheck just those properties or ignore it entirely, as it prefers.  If that handles only complex cases (eg, firstName was updated so the computed fullName needs to be updated) and set hooks handle the single-property ones, that would probably cover all bases reasonably well.

--Larry Garfield