Hi Mate, Quite some time after mentioning the "clone with" construct the first time > (at the end of the > https://wiki.php.net/rfc/write_once_properties#run-time_behaviour > section), > finally I managed to create a working implementation for this feature which > would make it possible to properly modify readonly properties > while simplifying how we write "wither" methods: > https://wiki.php.net/rfc/clone_with >
Thanks for working on this, we definitely need improvements on the topic. Thanks also for mentioning my proposal and for the comparison analysis, that's really helpful. Quoting from the RFC: > One cannot control whether $this should really be cloned: e.g. if a property should only be modified based on certain conditions (e.g. validation), the object would potentially be cloned in vain, resulting in a performance loss. Returning a clone or the same instance depending e.g. on some validation is usually an abstraction leak. It's a leak because it allows knowing internal implementation details by comparing the identity of the resulting objects. Since the PHP community is leaning towards more strictness and better abstractions, I think this point is actually a win for my proposal: it'd naturally close the loophole in wither-based abstractions. See https://3v4l.org/02IVc#v8.2.5 if what I mean is unclear. > Sometimes one also needs access to the original instance, but doing so would only be possible via workarounds (e.g. by introducing $that or a similar construct). Here is how we would achieve this under my proposal (adapting from your example): class LinkedObject { /*...*/ public function next(): static { $clone = $this->prepareNext(); $clone->next = $this; return $clone; } private clone function prepareNext(): static { $this->number++; unset($this->next); return $this; } } As you can see, this works by *not* using the clone keyword on the public method. And this makes me realize that what you see as an advantage ("it could be made part of the interface contract") might actually be a drawback, by forcing a coupling between a contract and an implementation. That's what you mean also with your last sentence on your analyses. And that kills my proposal, RIP :) But I have another proposal I'm sending separately. Nicolas
