Re: [RFC] Clone with v2
> On 15 May 2025, at 06:26, Volker Dusch <[email protected]> wrote:
>
> On Wed, May 14, 2025 at 10:06 PM Matthew Weier O'Phinney <[email protected]
> <mailto:[email protected]>> 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
Thread (26 messages)