Re: Re: [RFC] Clone with v2

From: Date: Wed, 21 May 2025 14:27:07 +0000
Subject: Re: Re: [RFC] Clone with v2
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-127415@lists.php.net to get a copy of this message
Hi Tim, Le mer. 21 mai 2025 à 16:15, Tim Düsterhus <tim@bastelstu.be> a écrit : > 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”. > > 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 .c�«> > ÄGæi'á•Ëà 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")); > > Thanks for sharing your insights. This looks a bit far reaching for the RFC.. On my side, my opinion is: don't make clone a function call. I've never missed not being able to call clone as a callback. It's trivial to write a short function using the operator when in need. Nicolas

« previous php.internals (#127415) next »