Re: [PHP-DEV] [RFC] Asymmetric visibility

[Andreas Heigl]

Hey Marco.

On 08.08.22 10:14, Marco Pivetta wrote:

Heyo Andreas, Casper,

On Mon, 8 Aug 2022 at 10:03, Andreas Heigl <andr...@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.

Just my 0.02€

Cheers

Andreas
--
                                                              ,,,
                                                             (o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andr...@heigl.org                  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org                                           |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas                               |
+---------------------------------------------------------------------+

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.

OpenPGP_0xA8D5437ECE724FE5.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature