Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119055
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
In-Reply-To: <cb2ca327-fc62-4c2d-bde1-f95d50f53c49@app.fastmail.com>
Date: Wed, 30 Nov 2022 12:25:20 +0700
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <E87781C5-4C07-4C47-93D8-0188794D0D0F@koalephant.com>
References: <0854b030-c51c-4c1b-a7dd-22835a1e5da9@app.fastmail.com>
 <831b9906-dc0c-420c-b22f-8a0cc8a1ad64@app.fastmail.com>
 <434BDABD-8551-46C8-98EC-8CA87952AE25@gmail.com>
 <cb2ca327-fc62-4c2d-bde1-f95d50f53c49@app.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
From: php-lists@koalephant.com (Stephen Reay)



> On 30 Nov 2022, at 08:27, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> On Tue, Nov 29, 2022, at 5:46 PM, Claude Pache wrote:
>=20
>> In the RFC, section Permitted visibility=20
>> (https://wiki.php.net/rfc/asymmetric-visibility#permitted_visibility=20=

>> =
<https://wiki.php.net/rfc/asymmetric-visibility#permitted_visibility>):
>>> The set visibility, if it differs from the main (get) visibility, =
MUST be strictly lesser than the main visibility. That is, the set =
visibility may only be protected or private. If the main visibility is =
protected, set visibility may only be private. Any violation of this =
rule will result in a compile time error.
>>>=20
>> The first sentence does not forbid `public public(set)`, or =
`protected=20
>> protected(set)`, etc. (the `set` visibility does not differ from the=20=

>> main visibility), but the rest of the paragraph does not allow it. =
That=20
>> should be clarified.
>=20
> Er.  That's exactly what it says: "strictly lesser" than the main =
visibility.  The lines after are just restating it.  "public =
public(set)" is not allowed.
>=20
> (We may relax that in the future to make it compatible with readonly, =
but that's for later.)
>=20
>>=20
>> (Because forbidding `public public(set)`, etc., makes it slightly =
more=20
>> cumbersome to explain the rules, I am slightly in favour not to =
forbid=20
>> it.)
>>=20
>>> There is one exception, that of a private readonly property. That =
would technically expand to private private(set) readonly, which is =
allowed.
>>=20
>> That sentence should be deleted, as `readonly` is now forbidden.
>=20
> Good catch, fixed.  Thanks.
>=20
> --Larry Garfield
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>=20

Hi Larry,

Thank you for clarifying the setter behaviour in more explicit terms, =
but I have to say I=E2=80=99m quite disappointed in this continued =
=E2=80=9Cuse the logic of readonly to apply to something that is =
explicitly not readonly=E2=80=9D - this is even more stark now that =
you=E2=80=99ve explicitly made them mutually exclusive behaviours.

I=E2=80=99m generally very in favour of maintaining consistency, but =
this seems like it=E2=80=99s using technical consistency as an excuse to =
justify unintuitive behaviour that breaks consistency in another, much =
more obvious way.


Can you explain why it makes more sense to maintain consistency with =
=E2=80=9Creadonly=E2=80=9D than it does to maintain consistency with the =
existing =E2=80=9C__set()=E2=80=9D behaviour for properties, =
particularly now that you=E2=80=99ve indicated these features =
(asymmetric visibility and readonly) are mutually exclusive?=20

While it=E2=80=99s stated multiple times that =E2=80=9Creadonly=E2=80=9D =
introduced a limited form of asymmetric visibility, and thus this is a =
continuation, in terms of intuitiveness, the existing __set() rules are =
very easy to comprehend even with readonly:

- if the property is declared as public, __set() is never called; if =
it=E2=80=99s declared as protected, __set is called when the property is =
accessed from outside that class or it=E2=80=99s hierarchy. Yes, I know =
that readonly imposes an implicit visibility difference - but that is =
essentially an implementation detail, from the point of view of the =
userland developer, it=E2=80=99s not a clear statement of intended =
behaviour on their part, expressed through the code as written.

For example, with `public readonly int $foo` it=E2=80=99s quite obvious =
why __set() isn=E2=80=99t called, using the exiting well-understood =
logic: it=E2=80=99s a public property. PHP applies a kind of asymmetric =
visibility to the property behind the scenes, but that isn=E2=80=99t =
what the developer declared, it=E2=80=99s the implementation. This =
behaviour matches that of regular, non-readonly fields: when the field =
is declared public (or has implicit public visibility) __set() is never =
called.

If we make that field protected, __set() will be called when the =
property is written to from outside the class, regardless of whether =
it=E2=80=99s readonly or not.


What you=E2=80=99re proposing changes that, in a way that is completely =
unintuitive: when attempting to *write* data to a property that is =
marked as protected(set), the __set() method will not be called.


So please, can you explain to me why consistency with an implementation =
detail of readonly properties is more important than consistency with =
declared developer intention for regular properties via the magic setter =
method?



Cheers

Stephen=20