On Wed, May 14, 2025, at 2:54 PM, Volker Dusch wrote:
> 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.
Please include this in the RFC.
> 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.
I think the current syntax is optimal.
>> 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.
The concern is someone calling clone($foo, object: new Thingie()), which would complain that
"object" is defined twice. Making the first argument named __object sidesteps that issue.
If someone then calls clone(prop: 'new val', __object: $foo), that... I suppose would
technically compile, but one should never do that, and I am perfectly happy if that breaks. Similar
for if someone called clone(prop: 'new val', object: $foo) if we didn't rename that
parameter. No one should be doing that and I am fine if that breaks.
--Larry Garfield