On Fri, May 16, 2025 at 8:46 PM Rowan Tommins [IMSoP] <[email protected]>
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