On Wed, May 14, 2025 at 5:40 PM Larry Garfield <la...@garfieldtech.com> 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
