Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130157
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 24 Feb 2026 13:32:07 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <96627211-d92f-4af4-ba45-6304a43e8575@app.fastmail.com>
In-Reply-To: <7FA75C32-BC65-487B-BE44-272FEED42F04@wcflabs.de>
References: <CE12E852-00AA-41E1-8E8A-B82B89F801A4@wcflabs.de>
 <CAGBsUrdczien7yCvQLNMQXOcJnZbmjOgAMQi4rD8uRxzkVsm8Q@mail.gmail.com>
 <7FA75C32-BC65-487B-BE44-272FEED42F04@wcflabs.de>
Subject: Re: [PHP-DEV] [RFC] Readonly Variables
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Feb 24, 2026, at 12:52 PM, Joshua R=C3=BCsweg wrote:

>> I would prefer starting with readonly parameters as I feel that would
>> bring the most value.
>
> I find the idea of readonly parameters interesting and have already=20
> given it some thought. However, it is out of scope for this RFC, as I=20
> wanted to keep the initial proposal focused and manageable. I have=20
> already mentioned it in the Future Scope section of the RFC as a=20
> potential natural extension that could be addressed in a separate RFC=20
> in the future.

A slight tangent here, but what would readonly parameters do?

If you pass something by value, then already you cannot modify the value=
 in the caller.  If the value is large, it's already kept efficient by c=
opy-on-write.

If you pass by reference, then presumably you *want* to modify the value=
 in the caller.

If the value is an object, then as already discussed, its internals are =
mutable either way so you gain little, but the function cannot change th=
e identity in the caller anyway.

So I don't see what readonly parameters would even accomplish.  The thin=
g they accomplish in JS or Java or C simply doesn't apply in PHP.

I'm still undecided at the moment on readonly variables.

--Larry Garfield