> Le 8 juil. 2025 à 17:32, Nicolas Grekas <nicolas.grekas+...@gmail.com> a > écrit : > > I read Claude's concern, and I agree with Larry's response: the engine > already allows readonly to be bypassed using __get. The added hook doesn't > make anything more lenient. >
It is true that readonly could be bypassed by __get(); but this is a legacy behaviour, and you have to take an explicit step to make it possible. For those unaware of the awful hack, here is a minimal test case: https://3v4l.org/N78An where the `unset(...)` is mandatory to make it “work”. Are we obligated to sanction shortcomings of legacy concepts in newly introduced concepts that are supposed to replace them? Or can we do something better? I’ve outlined in a previous email what I think is a better design for such situation (namely an `init` hook). Also, the fact that __get() is not yet deprecated means that we can still use the aforementioned hack until/unless we’ve implemented a proper solution. In the worst case, you can still use a non-readonly hooked property and document the intended invariants in phpdoc. > If a class is final and uses readonly with either hooks or __get, then that's > the original author's choice. There's no need for extra engine-assisted > strictness in this case. You cannot write such code in a non-readonly way by > mistake, so it has to be by intent. > Enforcing as strictly as possible its intended invariants is a good design for a robust language. Yes, it implies that users cannot (or can hardly) escape annoying constraints. For example, you can’t extend a final class, even if you think that you have good reason for it, like constructing a mock object. —Claude
