Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119040
MIME-Version: 1.0
References: <CAH5C8xUd4ueJ62pR6vT2haz9rFgrgspJQui1rPCqTneupD+tsQ@mail.gmail.com>
 <CADyq6sLFZpM1A+V-aa3dWjY1mL=65e-kxeiyBHABNPZR2GfpKQ@mail.gmail.com> <CADK1yX+9c3bkD8S1d-Ei3fRmWknQCHF2EXW9y96tFQkwUnse3Q@mail.gmail.com>
In-Reply-To: <CADK1yX+9c3bkD8S1d-Ei3fRmWknQCHF2EXW9y96tFQkwUnse3Q@mail.gmail.com>
Date: Sat, 26 Nov 2022 16:35:47 -0800
Message-ID: <CAMrTa2GefQAMOe-9wcNrpx_UMSJebHPN9XeNNewQ-JvJX-czLw@mail.gmail.com>
To: Deleu <deleugyn@gmail.com>
Cc: Marco Pivetta <ocramius@gmail.com>, =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e791f605ee68ef29"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Readonly class amendments
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000e791f605ee68ef29
Content-Type: text/plain; charset="UTF-8"

On Sat, Nov 26, 2022 at 3:40 PM Deleu <deleugyn@gmail.com> wrote:

>
> As I think more about this, there's nothing about the current RFC in this
> code sample. What's breaking LSP here is the child class doing state
> modification, not PHP.  To further expand that rationale, PHP allows us to
> create child classes. Whether that class will be LSP-safe or not is up to
> us, not up to PHP.
>
> However, the point still stands. Allowing child classes to break readonly
> will make it easier to build code that breaks LSP. The question then
> becomes: why is this being proposed and is it worth it?
>

I cannot help but feel that the way `readonly` is being treated is going to
end up one of those things that is regretted. "Readonly does not imply
immutability". The fact that very nearly *every* single person who has not
worked on the RFCs has at some point been confused by this however should
be very telling.

This comes from two *different* avenues that compound with each other to
*both* make this design head-scratching to me.

First, in virtually all other technical contexts where the term "readonly"
is used, it means that the information/data cannot be altered. That is not
the case with readonly. In PHP, in this implementation, it is not
"readonly" in the sense that it is used everywhere else for computing, it
is "assign once".

Second, the English words "read only", particularly to native speakers,
make this behavior very counterintuitive and confusing. I won't belabor
that point further.

What "read only" really is, is "constructor initialize only". It honestly
has nothing to do with "read" as it's implemented.

I guess I worry that this RFC makes `readonly` even more of a minefield for
PHP developers, increasing the mental load of using it in code while *even
further* watering down the benefits it may provide. It's already designed
in a somewhat counterintuitive way that I feel will be almost completely
replaced in actual code in the wild by "immutable" if PHP ever gets that.

LSP doesn't exist because it is some objectively better way of programming
according to universal laws of entropy or something. It is instead
important because LSP helps programmers be able to predict the behavior of
the program they are writing and reduces the short-term memory load
involved in programming and architecture.

Something that *technically* complies with LSP but makes the program harder
to predict and increases the mental load of programming violates the
*purpose* of LSP. We can argue about whether it is technically correct, but
I feel like that somewhat misses the point: making the language more
capable, more stable, and more predictable.

In other words, I do not believe it is that important or care to argue
about whether this RFC violates LSP. It violates the *purpose* of LSP, and
that's a bigger problem to me personally.

Jordan

--000000000000e791f605ee68ef29--