Re: [RFC] Clone with v2
On Wed, May 14, 2025 at 5:40 PM Larry Garfield <[email protected]>
wrote:
>> A magic __clone() method will be called before the new properties are
assigned.
> Why before and not after? I could probably make a good argument either
direction, but we should be explicit about why we're making whatever
decision.
From a user-facing perspective, calling __clone() before makes it easy to
know which state the object is in; all parameters are how they've been
before the clone operation started and are therefore consistent. When
calling __clone() afterward access to the new properties would already be
set and the old ones gone, making this potentially harder to work with and
harder to adapt existing implementations. So we chose the one that causes
fewer potential issues and gotchas.
> The last example, on readonly, is a bit confusing. It looks like it
should work, but the comments say "but if we did this other thing we'd get
this error." Just make it two separate classes and show one works and one
doesn't. That makes it easier to follow.
I've added the output to the var_dump statements to show what works.
Standalone examples for the "missing" (set) felt more confusing than
showing the difference in context and because its behavior is unaffected by
the RFC and mostly documented in case someone isn't familiar with this
detail in PHP, which I assume readers here will be.
>> Alternatively, we could drop the variadic syntax and instead only accept
an array as the second parameter. We're looking for feedback here in the
discussion.
> Oh lord please no. :-) Not using an array here is what I like about this
syntax. An __object parameter is fine with me as a workaround. One
shouldn't be using a named argument for that anyway.
Thank you for your feedback! I'm looking forward to hearing what other
people say as well, but it's nice to get a range of voices giving input
here :)
Let me just reiterate here that I find the difference to be minor to
negligible. IDE/Tooling support needs to be built explicitly either way and
is not harder or easier to do, and the ergonomics are quite unaffected in
my opinion. So the worst outcome, for me, would be that we get hung up on
the syntax here.
> One shouldn't be using a named argument for that anyway.
I'm not sure what you mean by that. Just so we're clear: `...["__object" =>
"foo"]` would also not work with the current implementation, as that's the
same thing as a __object: $value named argument. (Should we decide to
name the first parameter __object here). Sorry if I'm misunderstanding.
Kind Regards,
Volker
--
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
Thread (26 messages)