[RFC] [Discussion] Readonly Classes

php.internals

Máté Kocsis

4 years ago
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é

Ricardo Boss

4 years ago
Hi Máté, you seem to have a typo in your RFC: " Similarly how overriding of readonly properties works, only a readonly class can extend a readonly parent: class A {} readonly class B extends A {} " I think you meant to write `readonly class A {}` instead. Apart from that, I think readonly classes would be a great idea! Cheers! Ricardo

Michał Brzuchalski

4 years ago
Hi Máté, pon., 22 lis 2021 o 17:14 Máté Kocsis <kocsismate90@gmail.com> napisał(a):
> Hi Internals, > > I'd like to propose adding support for readonly classes: > https://wiki.php.net/rfc/readonly_classes
Did you forget to update the status? Cheers, Michał

Michał Brzuchalski

4 years ago
Hello Máté, pon., 22 lis 2021 o 17:14 Máté Kocsis <kocsismate90@gmail.com> napisał(a):
> 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 >
Personally, I'm not convinced at all about this idea. The read-only property for me is a preliminary step before introducing full-blown property/field accessors. Instead of making the whole class readable I'd rather see sort of data classes similar to record classes in other languages where you get pass-by-value, built-in object initializer and class composition over inheritance like Go structs. But regardless of what I'd love to see this feature, I see no justified use case. Therefore I ask if there are any real use cases of it? and if there are other languages with similar functionality? Cheers, Michał Marcin Brzuchalski

Larry Garfield

4 years ago
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

Máté Kocsis

4 years ago
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 not > 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, 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.)
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áté

Thomas Gutbier

4 years ago
Am 19.04.2022 um 09:58 schrieb Máté Kocsis:
> 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!
Should this rfc (https://wiki.php.net/rfc/deprecate_dynamic_properties) be considered here? The attribute #[AllowDynamicProperties] should not be allowed for readonly classes. Thomas

Máté Kocsis

4 years ago
Hi Thomas, The attribute #[AllowDynamicProperties] should not be allowed for
> readonly classes. >
Nice catch and I do agree with you, so I will add this restriction. Máté

Máté Kocsis

4 years ago
Hi Internals, As there's not much discussion, I will start voting on Wednesday. Cheers, Máté