Re: [RFC] Asymmetric visibility

Hey Marco. On 08.08.22 10:14, Marco Pivetta wrote:

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.

Your use case might not need them (though actually you are needing them, you just don't use them as language feature but via the static-analysis annotation) But when discussing language features we should always keep ALL users of the language in mind. And if a feature helps in providing ways to build more stable code on the language level then we should think about that from a point of view of *all* users. And when the feature is already used via static-analysis then why not implement that for use by *everyone* and not only those that have static analysis in their CI toolchain. Just my 0.02€ Cheers Andreas -- ,,, (o o) +---------------------------------------------------------ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +---------------------------------------------------------------------+ | https://hei.gl/appointmentwithandreas | +---------------------------------------------------------------------+

Attachment: [application/pgp-keys] OpenPGP public key OpenPGP_0xA8D5437ECE724FE5.asc
Attachment: [application/pgp-signature] OpenPGP digital signature OpenPGP_signature.asc