Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119067
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Thu, 1 Dec 2022 08:38:27 +0700
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>
 <E87781C5-4C07-4C47-93D8-0188794D0D0F@koalephant.com>
 <29f2a6a5-08f7-4abb-965f-56bb1cc49565@app.fastmail.com>
To: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
In-Reply-To: <29f2a6a5-08f7-4abb-965f-56bb1cc49565@app.fastmail.com>
Message-ID: <DAECEBAC-D0BA-401A-95DD-E37AD6FBA87D@koalephant.com>
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
From: php-lists@koalephant.com (Stephen Reay)



> On 30 Nov 2022, at 22:09, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> On Tue, Nov 29, 2022, at 11:25 PM, Stephen Reay wrote:
>=20
>> Hi Larry,
>>=20
>> Thank you for clarifying the setter behaviour in more explicit terms,=20=

>> but I have to say I=E2=80=99m quite disappointed in this continued =
=E2=80=9Cuse the=20
>> logic of readonly to apply to something that is explicitly not=20
>> readonly=E2=80=9D - this is even more stark now that you=E2=80=99ve =
explicitly made=20
>> them mutually exclusive behaviours.
>>=20
>> I=E2=80=99m generally very in favour of maintaining consistency, but =
this seems=20
>> like it=E2=80=99s using technical consistency as an excuse to justify=20=

>> unintuitive behaviour that breaks consistency in another, much more=20=

>> obvious way.
>>=20
>>=20
>> Can you explain why it makes more sense to maintain consistency with=20=

>> =E2=80=9Creadonly=E2=80=9D than it does to maintain consistency with =
the existing=20
>> =E2=80=9C__set()=E2=80=9D behaviour for properties, particularly now =
that you=E2=80=99ve=20
>> indicated these features (asymmetric visibility and readonly) are=20
>> mutually exclusive?=20
>>=20
>> While it=E2=80=99s stated multiple times that =E2=80=9Creadonly=E2=80=9D=
 introduced a limited=20
>> form of asymmetric visibility, and thus this is a continuation, in=20
>> terms of intuitiveness, the existing __set() rules are very easy to=20=

>> comprehend even with readonly:
>>=20
>> - if the property is declared as public, __set() is never called; if=20=

>> it=E2=80=99s declared as protected, __set is called when the property =
is=20
>> accessed from outside that class or it=E2=80=99s hierarchy. Yes, I =
know that=20
>> readonly imposes an implicit visibility difference - but that is=20
>> essentially an implementation detail, from the point of view of the=20=

>> userland developer, it=E2=80=99s not a clear statement of intended =
behaviour on=20
>> their part, expressed through the code as written.
>>=20
>> For example, with `public readonly int $foo` it=E2=80=99s quite =
obvious why=20
>> __set() isn=E2=80=99t called, using the exiting well-understood =
logic: it=E2=80=99s a=20
>> public property. PHP applies a kind of asymmetric visibility to the=20=

>> property behind the scenes, but that isn=E2=80=99t what the developer =
declared,=20
>> it=E2=80=99s the implementation. This behaviour matches that of =
regular,=20
>> non-readonly fields: when the field is declared public (or has =
implicit=20
>> public visibility) __set() is never called.
>>=20
>> If we make that field protected, __set() will be called when the=20
>> property is written to from outside the class, regardless of whether=20=

>> it=E2=80=99s readonly or not.
>>=20
>>=20
>> What you=E2=80=99re proposing changes that, in a way that is =
completely=20
>> unintuitive: when attempting to *write* data to a property that is=20
>> marked as protected(set), the __set() method will not be called.
>>=20
>>=20
>> So please, can you explain to me why consistency with an =
implementation=20
>> detail of readonly properties is more important than consistency with=20=

>> declared developer intention for regular properties via the magic=20
>> setter method?
>=20
> There's a couple of reasons.
>=20
> One, and arguably the most important, readonly and aviz being =
incompatible is, hopefully, a temporary situation.  There's some fiddly =
bits to work out design-wise, and based on earlier comments in the =
thread we're going to punt on that for now to avoid that dragging down =
the whole RFC.  I believe we absolutely should allow them together in =
the future (maybe in a later 8.3 RFC, maybe a future version, TBD), =
which means ensuring, now, that they are compatible in the future.  This =
approach involves the fewest future BC breaks.
>=20
> Second, I wouldn't call the current behavior of readonly a mere =
implementation detail.  It's weird and unexpected, I'd agree, but only =
as a side effect of previous design decisions, some of which are even =
older than readonly.  But it's an observed behavior that code can rely =
on, and in some cases does.  For example:
>=20
> =
https://peakd.com/hive-168588/@crell/php-tricks-lazy-public-readonly-prope=
rties
>=20
> The "unset a declared property to force it through __get once" is a =
trick that some ORMs use extensively.  readonly just inherited that, =
leading to the current behavior: __set depends on the write/set =
visibility of the property and its settedness.  This RFC doesn't change =
anything there. =20
>=20
> The alternative would be to have __set called always for a =
non-public-set property.  However, that is a place for bugs, as you then =
can't not have a back-door way to publicly set a property even if it's =
declared private(set).  (Or, you have to be very careful in your __set =
to avoid it.)  That is both inconsistent with the language today, and =
error prone.
>=20
> Finally, we're planning to work in the near-future on property hooks =
(aka property accessors), which would allow per-property custom set =
routines.  That would largely remove the issue entirely, as the use of =
__set would go way down and you'd basically never have to use it with a =
declared property, fancy tricks or no, so this issue would never come up =
at all.
>=20
> --Larry Garfield
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php

Hi Larry,


I think there must be some confusion somewhere, based on some of your =
comments.

I=E2=80=99m not suggesting that the =E2=80=9Cunset to force a **public** =
property to go through getter/setter methods=E2=80=9D logic should be =
specifically different.

I=E2=80=99m suggesting that when the decision is made to call __set or =
not, the properties **set** visibility is what should be considered, not =
it=E2=80=99s **get** visibility.

Your own comment even describes this behaviour: "leading to the current =
behavior: __set depends on the write/set visibility of the property"

But your RFC says that __set will depend on the **read/get** visibility =
of the property.


> you then can't not have a back-door way to publicly set a property =
even if it's declared private(set).  (Or, you have to be very careful in =
your __set to avoid it.)  That is both inconsistent with the language =
today, and error prone.

If a developer adds a _set() method that can write to a private(set) =
property, I would expect that is working exactly as desired, exactly as =
it does **now** where it=E2=80=99s just a =E2=80=9Cprotected=E2=80=9D =
property.


> we're planning to work in the near-future on property hooks

That=E2=80=99s great, but I don=E2=80=99t think weird unintuitive =
behaviour should be added because =E2=80=9Cwell we=E2=80=99re gonna try =
and solve this through something else later=E2=80=9D



Cheers

Stephen=20