Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118385
Message-ID: <C7124120-30F1-4D4F-8569-C928AC63B999@koalephant.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_7E320DB1-2F78-4AE8-B96E-0CE2EFD8A018"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Mon, 8 Aug 2022 16:09:57 +0700
In-Reply-To: <ec4bc6e5-39ac-4a36-9d63-cca8dc6a29a6@www.fastmail.com>
Cc: php internals <internals@lists.php.net>
To: Larry Garfield <larry@garfieldtech.com>
References: <ec4bc6e5-39ac-4a36-9d63-cca8dc6a29a6@www.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Asymmetric visibility
From: php-lists@koalephant.com (Stephen Reay)

--Apple-Mail=_7E320DB1-2F78-4AE8-B96E-0CE2EFD8A018
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On 6 Aug 2022, at 00:08, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> Ilija Tovilo and I are happy to present the first new RFC for PHP 8.3: =
Asymmetric Visibility.
>=20
> https://wiki.php.net/rfc/asymmetric-visibility
>=20
> Details are in the RFC, but it's largely a copy of Swift's support for =
the same.
>=20
> --=20
>  Larry Garfield
>  larry@garfieldtech.com
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>=20

Hi Larry,


I like most of this, but I have one disagreement.

Can you expand a bit more on the reasoning for restricting the ability =
to combine __set() here?

The RFC states that it=E2=80=99s to keep consistency with `readonly`, =
because __set on a readonly property that=E2=80=99s initialised throws =
an error - but isn=E2=80=99t that because of the nature of it being =
readonly, rather than because of the visibility rules? The error given =
is "Cannot modify readonly property=E2=80=9D thrown from within the =
__set() method, not "Cannot access protected property=E2=80=9D thrown =
from the outside calling context, when the __set() method is not =
implemented.

If I set a property to readonly I would expect it to not be settable =
after initialisation, regardless of visibility, whether it=E2=80=99s via =
direct access or via __set, etc. (i.e. what readonly does now)

But if I set a property to `public private(set)` for example, I would =
**expect** that the __set method on that class (or in the hierarchy if =
using protected(set)) would be called when setting it from an =
inaccessible context, just as it would be called when setting a regular =
protected property.


It seems very unintuitive to me, that the first example here would work, =
but that the second would not work:

class Foo {
   =20
    protected readonly int $bar;
   =20
    public function __set(string $name, mixed $value): void {
        $this->{$name} =3D $value;
    }
}

$a =3D new Foo;
$a->bar =3D 1;


class Bar {
   =20
    public protected(set) int $baz;
   =20
    public function __set(string $name, mixed $value): void {
        $this->{$name} =3D $value;
    }
}

$b =3D new Bar;
$b->baz =3D 1;



Cheers

Stephen=20



--Apple-Mail=_7E320DB1-2F78-4AE8-B96E-0CE2EFD8A018--