Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118382
MIME-Version: 1.0
References: <ec4bc6e5-39ac-4a36-9d63-cca8dc6a29a6@www.fastmail.com>
 <CABdc3WqQ-kLTa3C=61_=yW-yJZuP2p_QW1TNe12WuHHur7aHng@mail.gmail.com>
 <e122e44f-550e-4089-8100-a27df9f8c9fa@www.fastmail.com> <CAKxcST_Mu3qDKKLgtsBBVAm=6mLirhjZ-88f+jjWeNhWyzO16A@mail.gmail.com>
 <A78DA1F7-1F74-4A94-962C-0EA5979431AD@gmail.com> <CANS-=pfq1Q+aK6CWTGKpiSH_M4PABQwb-65HqznDw_xzoDM8+Q@mail.gmail.com>
 <a6bc6a0a-912e-4c0f-9571-7fb920f1d90c@www.fastmail.com> <640e0f95-de30-4c53-48e8-818fdf408112@heigl.org>
 <c2eb4cdb-6064-4c37-8b90-24ae2556cc18@www.fastmail.com> <ecb9608d-a8db-065d-8a5c-cad363a5c0f3@heigl.org>
In-Reply-To: <ecb9608d-a8db-065d-8a5c-cad363a5c0f3@heigl.org>
Date: Mon, 8 Aug 2022 10:14:50 +0200
Message-ID: <CADyq6s+8DPZbH7bbQ+WQSdO9SOt_75tP4KkBhT3KBeJfm4PnOw@mail.gmail.com>
To: Andreas Heigl <andreas@heigl.org>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009eb8c805e5b669c5"
Subject: Re: [PHP-DEV] [RFC] Asymmetric visibility
From: ocramius@gmail.com (Marco Pivetta)

--0000000000009eb8c805e5b669c5
Content-Type: text/plain; charset="UTF-8"

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/

--0000000000009eb8c805e5b669c5--