On 15/05/2025 18:56, Stephen Reay wrote:
I agree that no __clone and an empty __clone should behave the same way. But as I said, I believe they should behave the same way as they do *now*, until the developer opts in to support cloning with new values.
I think what Andreas is saying is that the behaviour of this:
$foo = clone($bar, someProperty: 42);
Should be consistent with the existing behaviour of this:
$foo = clone $bar;
$bar->someProperty = 42;
An empty or missing __clone method won't prevent someProperty being assigned in the existing case, and for everything other than readonly properties, the new syntax is purely sugar for the existing one.
If I understand the RFC, the only change in behaviour is for readonly properties, which are "unlocked" during the "clone with" process. That means that if they were previously validated only in the constructor, this syntax can put the object in an unexpected state.
However, readonly properties are "protected(set)" by default, so the situations where this can happen are actually quite limited:
- Code inside the class itself (private scope) can reasonably be considered to be "opting in" to the feature it's using.
- Code in a sub-class (protected scope) can by default over-ride the constructor anyway.
- Code outside the class (public scope) will fail unless the property is explicitly "readonly public(set)", which would be pointless if it was always initialised in the constructor.
So the only case I can think of where something surprising could happen is:
1. A public or protected readonly property is initialised in a constructor marked "final"
2. A sub-class adds code that uses "clone with" to set that property to a new value
The question then is, how worried are we about that scenario?
--
Rowan Tommins
[IMSoP]