Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124510
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-568-g843fbadbe-fm-20240701.003-g843fbadb
Precedence: bulk
MIME-Version: 1.0
Message-ID: <284c6693-d9bf-4495-adc1-3cc8d5e54ee5@app.fastmail.com>
In-Reply-To: <b5c0be62-ea39-47fb-a8f8-ab6cd5ee3dab@app.fastmail.com>
References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com>
 <b5c0be62-ea39-47fb-a8f8-ab6cd5ee3dab@app.fastmail.com>
Date: Sat, 20 Jul 2024 15:46:36 +0200
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2
Content-Type: multipart/alternative;
 boundary=5295d6dfaff544ce898a1cd5f57c6898
From: rob@bottled.codes ("Rob Landers")

--5295d6dfaff544ce898a1cd5f57c6898
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 20, 2024, at 03:14, Larry Garfield wrote:
> On Wed, May 29, 2024, at 2:15 PM, Larry Garfield wrote:
> > As promised, Ilija and I offer this revised version of asymmetric vi=
sibility. =20
> >
> > https://wiki.php.net/rfc/asymmetric-visibility-v2
> >
> > It's still essentially the same as last year's version, but with a f=
ew=20
> > adjustments and changes:
> >
> > * readonly properties are now supported in a logical fashion.
> > * We've brought back the abbreviated form, as public-read, something=20
> > else set is the most common use case.
> > * The section on magic methods has been greatly simplified.  The=20
> > implementation itself hasn't changed, but the explanation is a lot l=
ess=20
> > confusing now.
> > * We've explained how aviz interacts with hooks (they don't, really)=20
> > and with interface properties (in the obvious way), which didn't exi=
st=20
> > at the time of the last draft.
> > * We've added a section with examples of how aviz is a concrete=20
> > improvement, even in a world with readonly and hooks.
> > * We've added a section discussing why the prefix-style syntax was=20
> > chosen.
>=20
> Hi folks.  After a side quest to polish off hooks, we're nearly ready =
to bring aviz to a vote.
>=20
> We've made one change since we last discussed it:  Specifically, Ilija=
 realized that __set's behavior is already inconsistent, so supporting i=
t for aviz properties with invisible set would make it even more inconsi=
stent, not less.  For that reason, we've changed the __set behavior such=
 that a non-readonly aviz property will not trigger __set.  Further deta=
ils are in the RFC, but in short, all of the use cases for that behavior=
 now have better alternatives, such as property types, hooks, and aviz i=
tself.  So there's really no point to falling back to __set in edge case=
s.
>=20
> https://wiki.php.net/rfc/asymmetric-visibility-v2#interaction_with_set=
_and_unset
>=20
> Baring any new developments, we plan to start the vote early next week.
>=20
> Cheers.
>=20
> --Larry Garfield
>=20

Hmm,

There=E2=80=99s a lot of existing code that relies on this behavior, it=E2=
=80=99s pretty much the best way to create proxies without requiring cod=
e generation.

This is a pretty massive breaking change.=20

=E2=80=94 Rob
--5295d6dfaff544ce898a1cd5f57c6898
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Sat, Jul 20,=
 2024, at 03:14, Larry Garfield wrote:<br></div><blockquote type=3D"cite=
" id=3D"qt" style=3D""><div>On Wed, May 29, 2024, at 2:15 PM, Larry Garf=
ield wrote:<br></div><div>&gt; As promised, Ilija and I offer this revis=
ed version of asymmetric visibility.&nbsp;&nbsp;<br></div><div>&gt;<br><=
/div><div>&gt;&nbsp;<a href=3D"https://wiki.php.net/rfc/asymmetric-visib=
ility-v2">https://wiki.php.net/rfc/asymmetric-visibility-v2</a><br></div=
><div>&gt;<br></div><div>&gt; It's still essentially the same as last ye=
ar's version, but with a few&nbsp;<br></div><div>&gt; adjustments and ch=
anges:<br></div><div>&gt;<br></div><div>&gt; * readonly properties are n=
ow supported in a logical fashion.<br></div><div>&gt; * We've brought ba=
ck the abbreviated form, as public-read, something&nbsp;<br></div><div>&=
gt; else set is the most common use case.<br></div><div>&gt; * The secti=
on on magic methods has been greatly simplified.&nbsp; The&nbsp;<br></di=
v><div>&gt; implementation itself hasn't changed, but the explanation is=
 a lot less&nbsp;<br></div><div>&gt; confusing now.<br></div><div>&gt; *=
 We've explained how aviz interacts with hooks (they don't, really)&nbsp=
;<br></div><div>&gt; and with interface properties (in the obvious way),=
 which didn't exist&nbsp;<br></div><div>&gt; at the time of the last dra=
ft.<br></div><div>&gt; * We've added a section with examples of how aviz=
 is a concrete&nbsp;<br></div><div>&gt; improvement, even in a world wit=
h readonly and hooks.<br></div><div>&gt; * We've added a section discuss=
ing why the prefix-style syntax was&nbsp;<br></div><div>&gt; chosen.<br>=
</div><div><br></div><div>Hi folks.&nbsp; After a side quest to polish o=
ff hooks, we're nearly ready to bring aviz to a vote.<br></div><div><br>=
</div><div>We've made one change since we last discussed it:&nbsp; Speci=
fically, Ilija realized that __set's behavior is already inconsistent, s=
o supporting it for aviz properties with invisible set would make it eve=
n more inconsistent, not less.&nbsp; For that reason, we've changed the =
__set behavior such that a non-readonly aviz property will not trigger _=
_set.&nbsp; Further details are in the RFC, but in short, all of the use=
 cases for that behavior now have better alternatives, such as property =
types, hooks, and aviz itself.&nbsp; So there's really no point to falli=
ng back to __set in edge cases.<br></div><div><br></div><div><a href=3D"=
https://wiki.php.net/rfc/asymmetric-visibility-v2#interaction_with_set_a=
nd_unset">https://wiki.php.net/rfc/asymmetric-visibility-v2#interaction_=
with_set_and_unset</a><br></div><div><br></div><div>Baring any new devel=
opments, we plan to start the vote early next week.<br></div><div><br></=
div><div>Cheers.<br></div><div><br></div><div>--Larry Garfield<br></div>=
<div><br></div></blockquote><div><br></div><div>Hmm,<br></div><div><br><=
/div><div>There=E2=80=99s a lot of existing code that relies on this beh=
avior, it=E2=80=99s pretty much the best way to create proxies without r=
equiring code generation.<br></div><div><br></div><div>This is a pretty =
massive breaking change.&nbsp;</div><div><br></div><div id=3D"sig1212291=
52">=E2=80=94 Rob<br></div></body></html>
--5295d6dfaff544ce898a1cd5f57c6898--