Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117540
MIME-Version: 1.0
References: <CAH5C8xUn9fD5=hkKQL+CMWSMXEugpX=HbSRcWQ3WTksCpXdt_A@mail.gmail.com>
 <4c685dfa-2a81-4eed-af70-3e34b7de50f0@www.fastmail.com>
In-Reply-To: <4c685dfa-2a81-4eed-af70-3e34b7de50f0@www.fastmail.com>
Date: Tue, 19 Apr 2022 09:58:57 +0200
Message-ID: <CAH5C8xUbOqd+BLPPDxrocz4M=MGjuYRBjxGV0Kw0nrVjKq0QFA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005ce49305dcfd4036"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Readonly Classes
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000005ce49305dcfd4036
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Everyone,

After quite a long pause, I'd like to revive the discussion of readonly
classes and possibly put it to vote in the coming week(s).

If I'm following, then this RFC is about 90% syntactic sugar for putting
> `readonly` on all properties, plus disabling dynamic properties.  That's
> the long-and-short of it, yes?
>

Yes, exactly!


> Does disabling dynamic properties offer any other advantages as have been
> discussed otherwise recently?  (E.g., performance.)
>

No, I'm not aware of any other advantages. The only reason why I included
this feature into the current RFC is because otherwise a readonly class
wouldn't be readonly. :)
The same applies for forbidding the declaration of static properties.

Is there a way to opt a given property back OUT of being readonly, or if
> you have a readonly class and need to add a single mutable property to it
> are you stuck adding `readonly` to all existing properties first?  (I'm n=
ot
> sure I'm suggesting having such a mechanism, mostly just clarifying.)
>

Yes, you are right. This is an inconvenient situation for sure, but neither
I can imagine any other way to back a property out of being readonly than
to remove
the readonly class modifier + add readonly property modifier where
possible. Of course, the readonly property modifier doesn't apply to the
internal state of objects...
so doing the above is not necessary if you have to modify a readonly
property which is an object.


> It's interesting that this also provides a backdoor way to force all
> properties to be typed, as a side effect.  However... that also means you
> cannot mark a class readonly if any of its properties are callables, sinc=
e
> callables cannot be typed. (I guess you could use mixed and then docblock
> callable, which is a bit fugly but not a problem introduced by this RFC.)


Yeah, you are right, an ugly hack is to use the mixed type for properties
that cannot be typed otherwise (e.g. resource). I believe in case of
callables, one could use
the Closure type instead, especially since the first-class callable syntax
has been introduced.

I hope I managed to address your questions/concerns.

M=C3=A1t=C3=A9

--0000000000005ce49305dcfd4036--