Hi Marco, Sorry for the very late reply!
As explained in > https://github.com/lcobucci/jwt/pull/979#discussion_r1025280053, a > consumer relying on a `readonly` > implementation of a class probably also expects replacement implementations > as read-only. > I am aware that we lack the `readonly` marker at interface level (would be > really neat), but the practical example is as follows: > Regarding readonly interfaces: it would be a good idea given properties were be able to be declared in interfaces. Then readonly interfaces could adopt the same semantics as readonly classes have, so that all *declared* properties become readonly. Regarding the LSP violation: your example is about immutability (as the name of the classes also suggest), but the readonly keyword doesn't guarantee immutability. This is basically what Nicolas answered not long ago to Larry: https://externals.io/message/118554#118604 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"; > } > } We proposed this change because it wouldn't break anything that's already not "broken". Regards: Máté
