> On 15 May 2025, at 06:26, Volker Dusch <vol...@tideways-gmbh.com> wrote: > > On Wed, May 14, 2025 at 10:06 PM Matthew Weier O'Phinney > <mweierophin...@gmail.com <mailto:mweierophin...@gmail.com>> wrote: > > > The only question that arose for me is: what happens if a property name is > > provided to `clone()` that does not exist in the class definition; what > > will be the behavior at that time? Will an exception or error be thrown? If > > so, will it be a new one, or an existing one? > > Thank you for the question. I had that one myself looking at the initial > implementation and forgot to write that down more explicitly. > > Tim already answered and linked the test, but I've also added an example to > the RFC. > > -- > Volker Dusch > Head of Engineering > Tideways GmbH > Königswinterer Str. 116 > 53227 Bonn > https://tideways.io/imprint > > Sitz der Gesellschaft: Bonn > Geschäftsführer: Benjamin Außenhofer (geb. Eberlei) > Registergericht: Amtsgericht Bonn, HRB 22127
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. Cheers Stephen
