Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119065
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead
Mime-Version: 1.0
Message-ID: <a719c9d1-de30-41d2-b7ae-24dc53a57d90@app.fastmail.com>
In-Reply-To: 
 <CADK1yXLSVH0X=dteA=GO+=UPSzSDfCecALytjRFG-u+0QRyGWg@mail.gmail.com>
References: 
 <CAH5C8xUd4ueJ62pR6vT2haz9rFgrgspJQui1rPCqTneupD+tsQ@mail.gmail.com>
 <CADyq6sLFZpM1A+V-aa3dWjY1mL=65e-kxeiyBHABNPZR2GfpKQ@mail.gmail.com>
 <CAFPFaMKc-PQD8YD6yDWPrMONcJdYqFCXgyJZuZZBVsT7VSy89A@mail.gmail.com>
 <CADyq6sJxNQKvDNsT48tsG=AUS8snbGvuR332Yaip-krd+yynaQ@mail.gmail.com>
 <CAFPFaML4Xq7Oo+pN7cAj3aQt3y3et33EzsQhxhqNZA22nOUuNw@mail.gmail.com>
 <CADK1yXLSVH0X=dteA=GO+=UPSzSDfCecALytjRFG-u+0QRyGWg@mail.gmail.com>
Date: Wed, 30 Nov 2022 13:35:01 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] [Discussion] Readonly class amendments
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Nov 30, 2022, at 9:46 AM, Deleu wrote:
> After reading GPB, Nicolas, Jordan and Larry's considerations, I no longer
> have any objections to this RFC. Here is my summary of it all:
>
> - It's very easy for everyone to wrongly interpret readonly as somewhat
> immutable, but it isn't (docs/education issue)
> - LSP is about the writer of the child class, not about PHP
> - If you don't want child classes to violate LSP, make your class `final
> readonly`
> - readonly as "constructor-init" properties mindset make it even stronger
> the argument that child classes should be free to choose their definition
> because constructors are special methods not bound by inheritance.

Just for the record, my whole point is that "readonly as constructor-init" is wrong, and I am angry at the SA tools that have invented that out of whole cloth because it just breaks workflows that I am using very effectively and safely.  I always turn off that check in those because they are wrong.  That is *not* how the language feature is implemented, so making other language feature decisions based on that incorrect, artificial "rule" is highly dangerous.

--Larry Garfield