Re: [RFC] Primary Constructors

On Mon, Jun 29, 2026 at 2:01 PM Larry Garfield <larry@garfieldtech.com> wrote: > > On Sun, Jun 28, 2026, at 7:17 PM, Rob Landers wrote: > > Hello internals, > > > > I'd like to put forward Primary Constructors > > <https://wiki.php.net/rfc/primary-constructors> for > > comment. > > > > An implementation PR will be opened later today (UTC), and the RFC > > updated with this discussion thread. > > > > — Rob > > I support this feature, and am glad to see it. It will make struct-objects that much easier to > write, as well as more interesting value objects. > > To the objections about readonly... Seriously, readonly is broken. :-) Use private(set) > instead and you get essentially the same effect, unless you're doing something screwy inside > your class. And if you are, then you already know it. > > As Rob already noted, there's a massive number of existing classes where it's not > even an issue: There's no hooks or need for them, and readonly works fine then. Or switching > them over to private(set) if adding a hook in the future is not hard. (Unless there's > inheritance involved, and then the problem is inheritance. :-) ) > > We can't remove readonly from the language, but we should not allow its limitations and > flaws to keep us from making our lives easier. I'm afraid of going off-topic, but I disagree that "readonly is broken." In what way is it broken? A large part of the disagreement in the previous "readonly hooks" RFC was over the *meaning* of readonly. I'd have to fully go back to remind myself of the nuance, but my recollection is that it works exactly how I (and others, per the vote outcome) expect. I recall that it seemed like what people wanted was to have something only *publicly* readable, but internally writable, which is in fact what you're suggesting as an alternative - asymmetric visibility (private(set)) - and is not what readonly is for, even if the name lends itself to confusion. I think you had even described it as "write-once", at one point, which more closely matches my expectation and desire of the keyword. I recall that I (and someone else?) had thrown out a suggestion for "init" hooks, that I think would have addressed what some people were looking for (having a hook with a readonly property for initialization), but not others (get hooks for readonly, since that breaks the "main" interpretation of the readonly RFC). Again, this was a while ago so I'm a little fuzzy, but I would absolutely consider voting yes for an "init" hook RFC; I could arguably see that as compatible with the readonly keyword, and thus, readonly would be compatible with (a subset of) hooks. This is not meant to be a combative email by the way, I just want to make sure it's clear that I believe readonly is not something that we should remove or consider baggage.