On Tue, Jul 22, 2025, at 12:17, Claude Pache wrote: > > >> Le 22 juil. 2025 à 11:25, Rob Landers <rob@bottled.codes> a écrit : >> >> >>> >>>> Should I be able to mark this class as readonly? I would think so. >>> >>> I don’t think so. >>> >>> If you want to *document* the intended invariant, you can put a @readonly >>> tag in a phpdoc comment. >>> >>> Adding a `readonly` keyword should *enforce* the invariant; the added value >>> is that it would choke on bugs like the one you wrote just above, making it >>> debugging much easier. >> >> I’m not sure if you meant to, but I feel like you just argued for allowing >> readonly on hooks so that these kinds of bugs aren’t accidentally written… > > You are misinterpreting my statement, and I’m not sure how I could be clearer > (additional words will be subject to additional misinterpretation). I didn’t > say: “we should allow `readonly` somewhere”, but: “if we add `readonly` > somewhere, it should enforce what it means, not just document an intent”.
If words could only be interpreted one way, we wouldn't need lawyers and clergy. I think it is worth clarifying if you are willing. But I do think we agree that it should be enforced -- it just comes down to the what and how it is enforced. > >> >>> >>> >>>> The readonly keyword simplified that greatly, however, readonly has been >>>> neutered compared to regular classes in the last couple of versions. There >>>> are so many edge cases and non-implemented features with them -- mostly >>>> due to this exact argument you are making -- that they're nearly worthless >>>> to actually define immutable value objects in today's PHP. >>>> >>> >>> There are several issues with the readonly feature, mostly because of the >>> “worse-is-better” philosophy. But we can slowly correct the main issues >>> instead of making them worse. >>> >>> —Claude >> >> I think this is the main crux of the issue, right? There is one camp that >> says readonly means immutable and another that says readonly is read-only. >> These two viewpoints are not compatible despite having a lot of overlap. > > The original RFC explicitly and unambiguously gives the intended > interpretation, despite your attempts to find another interpretation in it. I > agree that the word “readonly” is badly chosen and confusing. But I don’t > agree that we should reinterpret any feature based on incorrect understanding > of its intent (unless, of course, there is consensus to reinterpret it). > > —Claude If it were unambiguous, we wouldn't be having this conversation. I'd also invite you to read the original discussion: https://externals.io/message/114729. Note that it is pretty clear that readonly and aviz/hooks overlap, even back then. We do need to discover this overlap, and how it overlaps. Maybe that isn't this RFC, but where they overlap, they should be able to be used together. Or not? I dunno. — Rob
