On Wed, May 21, 2025, at 9:13 AM, Tim Düsterhus wrote: > Hi > > Am 2025-05-19 12:48, schrieb Volker Dusch: >> We're still looking for feedback on the ...variadic approach to the >> Syntax: >> https://wiki.php.net/rfc/clone_with_v2#open_issues, as we only got one >> reply so far on the topic. > > I was hoping for some additional opinions here before adding my own, but > since this does not appear to happen, adding my personal opinion on this > matter now: > > *Some* property name being completely incompatible with “clone with” (no > matter how the first parameter is going to be called) is a limitation > that should not exist, it feels like a feature that is broken by design > and I think I really would hate it if the documentation of this RFC > would need a “Caution: It is not possible to reassign a property called > '$object', due to a parameter name conflict”.
I completely disagree here. The __ prefix is sufficient to solve the issue. A double underscore prefix has been understood to mean "internal to PHP, magic here" for at least 20 years. The chances of someone having a property called $__object are virtually nil, and if they do, they're already treading on naming that's reserved for PHP's use anyway so if it breaks, it's their own fault. > Adjusting the signature to `clone(object $object, array > $withProperties)` would not have this problem and I don't consider the > additional verbosity of an array literal to be a problem. Static > analysis tools already understand array shapes and would need > adjustments either way to understand the semantics. > > From an implementation PoV a regular array parameter would also be > simpler, since the implementation would be able to simply pass along the > input array, whereas the “variadic” syntax needs special handling to > combine positional parameters with named parameters into a single array > that is then used in the cloning process. > > Syntax-wise there might also be a middle-ground. Similarly to how this > RFC turns `clone()` into a function, the `array()` syntax also looks > like a function call and would naturally extend to named parameters. > While mixing positional and named parameters would probably get complex, > allowing purely named parameters would trivially be possible (without > any function call overhead). It would also allow using the > first-class-callable syntax with `array(...)`, something I would liked > to have in the past. A proof of concept PR is at: > > https://github.com/php/php-src/pull/18613 > > Combining named-parameter `array()` syntax with clone taking a array as > the second parameter would allow for the following, which might combine > the best of both worlds? > > clone($obj, array(foo: 1, bar: "baz", object: "this is not > blocked")); I completely disagree here as well. I actively dislike using an array here, as I do find quoting all the keys to be cumbersome. And I don't think we should go with a worse syntax in the hopes of it being improved later, when there may well be other unforeseen challenges there. (Eg, I have no idea if bare array keys would cause issues with constants.) Moreover, we have 15 years of training and coding standards and automation tools that say to never use array(), always []. Reversing that would be far more disruptive for the ecosystem, even if it turns out to be not too disruptive to the code. I strongly prefer the current syntax, and if the RFC changed to require an array I would strongly consider voting No on those grounds alone. --Larry Garfield
