On Mon, Nov 22, 2021, at 10:13 AM, Máté Kocsis wrote: > Hi Internals, > > I'd like to propose adding support for readonly classes: > https://wiki.php.net/rfc/readonly_classes > > The implementation heavily builds on the semantics of the already accepted > readonly properties RFC (https://wiki.php.net/rfc/readonly_properties_v2), > basically the only thing I had to implement in the PR are the following: > - Any declared property of a readonly class is implicitly treated as > readonly > - Creation of dynamic properties is forbidden > > Readonly classes would make it easier to declare immutable(-alike) classes, > especially if a class > contains a lot of properties. As a side-effect, one could already opt out > from dynamic properties > completely, which won't really be possible for quite some time, even if > https://wiki.php.net/rfc/deprecate_dynamic_properties passes. > > Regards: > Máté
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? Does disabling dynamic properties offer any other advantages as have been discussed otherwise recently? (E.g., performance.) 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 not sure I'm suggesting having such a mechanism, mostly just clarifying.) 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, since 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.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
