Re: [RFC] Asymmetric visibility

Heyo Andreas, Casper, On Mon, 8 Aug 2022 at 10:03, Andreas Heigl <andreas@heigl.org> wrote: > Hey Casper. > > On 08.08.22 09:54, Casper Langemeijer wrote: > > Hi all, > > > > In the discussion I sometimes see the terminology 'readonly' and > 'writable' being used. This is confusing because when the property is an > object that itself is mutable, there is nothing read-only about it. > > > > The terminology in the RFC seems right to me, and overall it seems solid. > > > > However, I'm not convinced this RFC is solving a real issue. I could not > find any reasoning in the RFC, except that Swift has a very similar > language feature. > > > > To me it solves the topic of making a property readable but not > writeable from the public while still allowing it to be written to > within the private or protected context. > > So enforcing usage of a public setter-metbhod but not having to use a > getter. > > Soemthing like this > > final class Foo > { > public private(set) string $username; > > public function changeUsernameTo(string $newUsername): self > { > if (! newUsernameIsUnique($newUsername) { > throw new RuntimeException('The username is not unique'); > } > $this->username = $newUsername; > > return $this; > } > } > > > readonly only solves that for immutable properties but there currently > is no way of solving that for mutable properties. > Similar question as Casper here: I use readonly properties aggressively, and I try to make the state as immutable as possible. In the **extremely** rare cases where public get and private set are needed, I rely on traditional getters and setters, which are becoming extremely situational anyway, and still work perfectly fine. If that doesn't work, then PHPStan/Psalm allow declaring @private, @internal, @phpstan-internal or similar mechanisms to restrict scope access. qossmic/deptrac also works wonders here, compared to PHP. In fact, I'm writing so few getters and setters these days, that I don't see why I'd need getter and setter semantics to creep into the language, especially mutable ones, not even with the reflection improvements. As for readonly, the reason we sometimes **cannot** use readonly is because current clone semantics can't work around readonly rules (discussed in the readonly RFC): https://3v4l.org/og8bn If we solved that, I think private(set) would become even more situational, if not completely unnecessary. Another puzzling area in this RFC is reference support: let's take the occasion to disallow references completely on asymmetric access, perhaps? It would be nice to see references gone for good. No need to pollute the engine for the edge case of ArrayAccess and similar APIs :P Marco Pivetta https://twitter.com/Ocramius https://ocramius.github.io/