On Fri, May 16, 2025 at 8:46 PM Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote:
> 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? > Your summary matches my ideas around the topic and I've updated the RFC [1] to better clarify that we consider touching __clone to be out of scope. >From our perspective, we are not worried about the Points (1&2) you raised and are not interested in solving this by providing parameters to __clone as the additional cost, issues, and complexity are not a worthwhile tradeoff in our eyes. Kind Regards, Volker [1] https://news-web.php.net/php.internals/127397 -- Volker Dusch Head of Engineering Tideways GmbH Königswinterer Str. 116 53227 Bonn https://tideways.io/imprint Sitz der Gesellschaft: Bonn Geschäftsführer: Benjamin Außenhofer (geb. Eberlei) Registergericht: Amtsgericht Bonn, HRB 22127
