Re: [PHP-DEV] [RFC] Primary Constructors

On Mon, Jun 29, 2026 at 2:01 PM Larry Garfield <[email protected]> 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.