Hey Claude, >> 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
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)
