On Tue, Jun 13, 2023, at 3:51 PM, Máté Kocsis wrote: > Hi Larry, > > In this case, if the `with` happens first, then the new address object is >> cloned needlessly, but that *probably* doesn't hurt anything. But $newAddr >> !== $p3->address. >> > > Yes, I agree with this: "clone $this with ["x" => "y"];" is the easiest to > mentally model as a shorthand for "$self = clone $this; $self->x = "y";". > If we agree with this model, then it would be weird to execute __clone() at > the end indeed. But I think Nicolas' example explained this fact much > better than I could. :) Also, separating __clone() from the rest of the > clone opcode would be . > > And you are right, some objects may be cloned unnecessarily, which doesn't > hurt, but isn't ideal for sure. I should mention that in ideal > circumstances (when all properties are readonly + all of them are > initialized during construction + none of them are mutable internally), > deep cloning is not 100% required, unless only for defensive programming > purposes. > > Regards, > Máté
Where all properties are readonly, and if an object those are *also* readonly, and all are assigned in the constructor... Yeah, that ideal case is kinda narrow, and likely will remain so for a long while yet. Whichever order it goes in, that should be documented explicitly and the reasoning for it included. (Feel free to pilfer my examples above extensively if that helps.) As for the syntax itself, my preferences, in order, would be: 1. clone $foo with (...), where (...) follows named-argument syntax in all its variants and forms, which includes ...$arr. 2. clone $foo with $array, where $array is an honest to goodness assoc array/array literal, created by any means the developer wants. Either of those are equally expressive; the first is, IMO, cleaner and easier to read/type, and probably nicer on static analysis tools, but they're still both equally expressive. Anything less than that is, IMO, creating unnecessary confusion about how the syntax behaves that will trip up developers left and right. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
