Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118690
MIME-Version: 1.0
References: <CAOWwgpk7uAkZD_CH5inbm8Ng8iVL5SZsz59Mpzgpc_iG42ei8Q@mail.gmail.com>
 <CAH5C8xU=eukkqn+PToG4-JT0vqjChhkY=kd_4t_ki9mXu1UMqQ@mail.gmail.com>
 <c20b9aae-fbbf-484e-b73b-b370e4783ada@www.fastmail.com> <CAOWwgpkp0ndSgnS4aOiWqf+omcfT0_AiP0P35SC4hDZw0KDoHw@mail.gmail.com>
 <e82e0d67-bd0e-4f8d-a572-ac99f9bbbe06@www.fastmail.com> <CAMrTa2FQ=FHSPdaHwOwirddkbkKiXjwdT9pPjCZ3ScER+28Ltw@mail.gmail.com>
 <aa0a6e10-42ee-44af-8a38-e9b9558bba76@www.fastmail.com>
In-Reply-To: <aa0a6e10-42ee-44af-8a38-e9b9558bba76@www.fastmail.com>
Date: Sun, 25 Sep 2022 19:57:01 +0200
Message-ID: <CAH5C8xUQy6-JYo1ZodazzP_jKnDSkNZZidw=MBRrMh0LQLi-Fg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>, Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000edcb405e9842477"
Subject: Re: [PHP-DEV] Re: Issues with readonly classes
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000000edcb405e9842477
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

I remembered the same thing, and am similarly baffled. How did the RFC pass
> if you can do something as simple as `public readonly stdClass $var;`? I
> thought I followed the discussion on that RFC, but apparently I missed
> something. I would have expected an example like above to block acceptanc=
e
> of the RFC. To be clear though, I'm mostly confused about what the
> convincing argument about this was, or if it was something that everyone
> else viewed as an uncontroversial aspect?
>

The readonly class RFC doesn't really bring anything new to the table, just
complements the readonly property RFC. The latter RFC
explicitly mentions that interior mutability of properties is not
restricted in any way. In my opinion, this is a wise and pragmatic approach=
,
so that use-cases like the body stream of PSR-7 remain possible. Please
note that the feature is called "readonly", not "immutable".

What's your take about 8.2? As I demonstrated, readonly classes are broken
> because of this propagation to child classes. Does that mean we should
> remove this constraint from 8.2? What about reverting the feature and
> considering it again for 8.3, after fixing it?


I agree with Tim, and I also think that both reverting and making any last
minute fundamental change is not a good idea, especially
because people don't have a clear agreement about how inheritance
should work. Readonly classes is an optional feature, so anyone
who wants proxies to work can simply not add the readonly flag to their
classes. Of course, it's a bit more tricky for library code,
but package authors should be aware of this gotcha. Having that said, I'll
try my best to fix the current shortcomings for PHP 7.3.

broken. see thread


I may be biased, but neither I would call the whole feature "broken". It
works as intended for many regular use-cases. However, as you
highlighted in the thread, there are some use-cases with which the
interoperability of readonly classes is suboptimal, to say the least.
This is because the RFC was designed with a conservative approach (e.g.
static properties and inheritance by non-readonly classes
are forbidden). This way, we'll be able to iteratively improve the feature,
while we minimize the risk of introducing undesirable behavior
which would be difficult to get rid of later. I know that there is a thin
line between "conservative" and "incomplete", but I do hope that
PHP 7.3 will be the first version where readonly properties become actually
useful.

Does anyone else recall this?  M=C3=A1t=C3=A9, are Jordan and I just imagin=
ing
> things?


It may be possible that the discussion extended to this question, but
neither me (author of the previous readonly properties RFC), nor
Nikita had intention to restrict the usage this way due to the reasons
detailed in the first paragraph.

Regards,
M=C3=A1t=C3=A9

--0000000000000edcb405e9842477--