Issues with readonly classes

>Hi Marco, > > > >IMO good as-is: can be relaxed later (8.3 or later), if anybody believes > >> it's a show-stopper. > >> > >Readonly classes don't really need to be lazy. > >> > > > >"Break things and move slow" doesn't feel right to me for the language. > > It's a new keyword that you have to opt into. So it's not breaking > anything. It just means you might not be able to use it for your use case > yet. > > (and before you say that third party code might add it, you can just say > you don't support it yet). >

> Hello Larry, > > >> Regarding your main question: I understand your problem with readonly >> > classes, and I'd be happy if we found a solution which fits your >> use-cases >> > and keeps consistency for the engine at the same time. To give you more >> > context about the inheritance related restriction in the RFC: I went with >> > forbidding the extension of readonly classes by non-readonly ones so that >> > the invariants of the parent (no dynamic or mutable properties are >> allowed) >> > don't occasionally get violated by the child. However, I cannot think >> about >> > a proper scenario now where this would cause any problems... I'm >> wondering >> > if anyone could come up with one? >> >> I don't have a real-world example, but a general pattern. The advantage >> of a readonly object (either conventionally like PSR-7 or enforced by the >> `readonly` keyword) is that you can store a reference to it without having >> to worry about it changing out from under you. That means you can code on >> the assumption that any data derived from that object is also not subject >> to change. >> >> If you accept a readonly object of type Foo, you would write code around >> it on that assumption. >> >> If you're then passed an object of type Bar extends Foo, which has an >> extra non-readonly property, that assumption would now be broken. Whether >> that counts as a Liskov violation is... a bit squishy, I think. >> >> Where that might be a problem is a case like this: >> >> readonly class Person { >> public function __construct(public string $first, public string $last) {} >> >> public function fullName() { >> return "$this->first $this->last"; >> } >> } >> >> class FancyPerson extends Person { >> public string $middle = ''; >> >> public function setMiddle(string $mid) { >> $this->middle = $mid; >> } >> >> public function fullName() { >> return "$this->first $this-middle $this->last"; >> } >> } >> >> class Display { >> public function __construct(protected Person $person) {} >> >> public function hello() { >> return "Hello " . $this->person->fullName(); >> } >> } >> >> Now, Display assumes Person is readonly, and thus fullName() is >> idempotent, and thus Display::hello() is idempotent. But if you pass a >> FancyPerson to Display, then fullName() is not safely idempotent (it may >> change out from under you) and thus hello() is no longer idempotent. >> >> Whether or not that problem actually exists in practice is another >> question. And to be fair, the same risk exists for conventionally-readonly >> classes today (PSR-7, PSR-13, etc.), unless they're made final. Arguably >> the safety signaling of a lexically readonly class is stronger than for a >> conventionally readonly class, so one would expect that to not be broken. >> But that's the case where a non-readonly child of a readonly parent can >> cause problems. >> > > Thanks for constructing this example, that's good food for thoughts. > Unfortunately, The code following readonly child class shows that this > safety you describe doesn't exist: > > readonly class FancyPerson extends Person { > private readonly stdClass $middle; > > public function setMiddle(string $mid) { > $this->middle ??= new stdClass; > $this->middle->name = $mid; > } > > public function fullName() { > return "$this->first $this-middle $this->last"; > } > }

>> Personally I'm undecided at the moment whether or not it should be >> allowed. I'm sympathetic to the "it's easier to disallow and allow later >> than vice versa" argument, but still not sure where I stand. The above at >> least gives a concrete example of where the problem would be. >> > > If we want the safety you describe, we might want a stronger version of it. > Let's name it immutable. An immutable property/class would be like a > readonly property with the additional restriction that only an immutable > value could be assigned to it (scalars + array + immutable classes.) But > that's another topic. > > Your example made me doubt for a moment, but without any convincing > purpose, this should help decide that child classes shouldn't have to be > readonly. > > Nicolas