Re: [RFC] Readonly property hooks

Hey Claude, >> Le 8 juil. 2025 à 17:32, Nicolas Grekas <nicolas.grekas+php@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 I hear you, but I still struggle to fully grasp the issue. It’s genuinely hard for me to come up with a real-world example that actually makes sense. Everything I’ve seen so far, including the RFC example and what I tried myself (I gave it an honest shot), feels either very theoretical or entirely intentional, and thus perfectly logical in its outcome. In one of your previous mails you brought up an example that requires calling a class method (read: intentionally changing class state), which would result in a non-consistent value being returned when calling the same property more than once. I get it. But what if the user wants exactly that in their readonly class? That said I did address your concern here (actual RFC PR branch against alternative; PoC): https://github.com/NickSdot/php-php-src/compare/allow-readonly-hooks...NickSdot:php-php-src:readonly-hooks-strict Larry and I agree that we don’t want this complexity in the current RFC. Perhaps this is something for a separate init hook RFC? Cheers, Nick (Sorry for the duplicate. I forgot to CC the list)