Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119069
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead
Mime-Version: 1.0
Message-ID: <355502b2-cdcd-4af9-8c4e-bb4d41880a41@app.fastmail.com>
In-Reply-To: <DAECEBAC-D0BA-401A-95DD-E37AD6FBA87D@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>
 <E87781C5-4C07-4C47-93D8-0188794D0D0F@koalephant.com>
 <29f2a6a5-08f7-4abb-965f-56bb1cc49565@app.fastmail.com>
 <DAECEBAC-D0BA-401A-95DD-E37AD6FBA87D@koalephant.com>
Date: Thu, 01 Dec 2022 12:14:14 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, with readonly
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Nov 30, 2022, at 7:38 PM, Stephen Reay wrote:

>>> So please, can you explain to me why consistency with an implementat=
ion=20
>>> detail of readonly properties is more important than consistency wit=
h=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 incompa=
tible 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 (may=
be in a later 8.3 RFC, maybe a future version, TBD), which means ensurin=
g, 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 imple=
mentation detail.  It's weird and unexpected, I'd agree, but only as a s=
ide effect of previous design decisions, some of which are even older th=
an readonly.  But it's an observed behavior that code can rely on, and i=
n some cases does.  For example:
>>=20
>> https://peakd.com/hive-168588/@crell/php-tricks-lazy-public-readonly-=
properties
>>=20
>> The "unset a declared property to force it through __get once" is a t=
rick that some ORMs use extensively.  readonly just inherited that, lead=
ing to the current behavior: __set depends on the write/set visibility o=
f the property and its settedness.  This RFC doesn't change anything the=
re. =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 p=
rivate(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 rout=
ines.  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 decla=
red property, fancy tricks or no, so this issue would never come up at a=
ll.
>>=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=20
> through getter/setter methods=E2=80=9D logic should be specifically di=
fferent.
>
> I=E2=80=99m suggesting that when the decision is made to call __set or=
 not, the=20
> properties **set** visibility is what should be considered, not it=E2=80=
=99s=20
> **get** visibility.
>
> Your own comment even describes this behaviour: "leading to the curren=
t=20
> behavior: __set depends on the write/set visibility of the property"
>
> But your RFC says that __set will depend on the **read/get** visibilit=
y=20
> of the property.
>
>
>> you then can't not have a back-door way to publicly set a property ev=
en if it's declared private(set).  (Or, you have to be very careful in y=
our __set to avoid it.)  That is both inconsistent with the language tod=
ay, and error prone.
>
> If a developer adds a _set() method that can write to a private(set)=20
> property, I would expect that is working exactly as desired, exactly a=
s=20
> it does **now** where it=E2=80=99s just a =E2=80=9Cprotected=E2=80=9D =
property.

I think we're talking past each other a bit. :-)

The logic described in the RFC is, to the best of out knowledge, what al=
ready happens in 8.1/8.2 with readonly.  Whether that is good or bad, ob=
vious or intuitive, it's what PHP already does, for better or worse.  We=
 view readonly as, effectively, a shorthand for "private(set) write-once=
" (which is what it is), and want to ensure that future RFCs can do that=
 explicitly so that we can allow `public protected(set) readonly` in the=
 future.

For that to be possible, not changing the existing behavior is a necessi=
ty.  Changing the behavior described in the RFC right now is a BC break.=
  That's true whether the logic described in the RFC is good or not, bec=
ause that's how it already works with `readonly`.

Is it weird that __set depends in part on read visibility?  Kinda, yeah.=
  But that's already the behavior in 8.1/8.2.  We're not changing anythi=
ng, and this RFC is not the place to break that kind of BC.

If someone can demonstrate that the logic described there is not what ac=
tually happens now, please let us know, because the goal is to not chang=
e any behavior in this regard.  Effectively, that whole section is descr=
iptive of PHP today and a comment "and we're not breaking it."

--Larry Garfield