Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123102
Precedence: bulk
MIME-Version: 1.0
References: <CAPyj-LBMQEJ=2BF=xk_on4O2xTU+MM2XRAZ5g=uPwVOf=bh+sw@mail.gmail.com>
 <66154AA0.1040905@adviesenzo.nl> <66160A1D.4060409@adviesenzo.nl>
 <CAL0xaBGbacGQuSOG0c0b7oeP=m5FMWRRYOqQjZ2FYwRK9ygaUA@mail.gmail.com> <e6e67a15-9e3d-4655-b870-519489bc1ffe@bastelstu.be>
In-Reply-To: <e6e67a15-9e3d-4655-b870-519489bc1ffe@bastelstu.be>
Date: Wed, 10 Apr 2024 23:17:48 +0300
Message-ID: <CAL0xaBFziySAcN+0ZzOQa24fOupG4sxu7gndjg3fn7gDbxLKPw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Vote announcement] Property hooks
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000a6a8400615c3bd7e"
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--000000000000a6a8400615c3bd7e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 10 Apr 2024 at 22:31, Tim D=C3=BCsterhus <tim@bastelstu.be> wrote:

> Hi
>
> On 4/10/24 10:28, Arvids Godjuks wrote:
> > The amount of complexity in these two hooks is on the level of the whol=
e
> > PHP OOP model with the number of footguns and WTF cases to rival magic
> > quotes, register_globals=3Don and every other infamous gotcha we had in=
 the
> > engine that got deleted out of existence.
>
> As someone who read the RFC like 20 times while it evolved (and just
> read it once more before submitting this email):
>
> Most of what the RFC spells out explicitly, because that's what RFCs
> need to, is a pretty much natural consequence of how the existing PHP
> features work. You cannot really shorten the RFC without either making
> it underspecified or useless.
>
> Is there some syntax that could technically be omitted? Sure. Would
> doing so meaningfully simplify the RFC? No, because most of the text
> length comes from the interaction of existing syntax and semantics with
> hooks and thus is an inherent property of property hooks (pun not
> intended). It's not the RFCs fault that references exist, or that
> casting an object to an array is legal, or whatever else needs to be
> explicitly spelled out.
>
> I also believe that the chosen syntax fits nicely with the existing
> syntax, borrowing syntax where useful and inventing new syntax where the
> existing syntax does not provide anything.
>
> It's a clear improvement over the status quo of __get() and __set(),
> especially from a third-party tooling perspective. I'm in favor.
>
> Best regards
> Tim D=C3=BCsterhus
>

Yeah we had a discussion with Larry on SF Slack, he made some things clear
that it's either all or nothing, because once they dove in, it became clear
that there's no way to gradually to introduce it. So, if it passes, the
community is just gonna have to deal with the massive scope of it if they
want the hooks or forget about them.
--=20

Arv=C4=ABds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

--000000000000a6a8400615c3bd7e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, 10 Apr 2024 at 22:31, Tim D=
=C3=BCsterhus &lt;<a href=3D"mailto:tim@bastelstu.be">tim@bastelstu.be</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi<br=
>
<br>
On 4/10/24 10:28, Arvids Godjuks wrote:<br>
&gt; The amount of complexity in these two hooks is on the level of the who=
le<br>
&gt; PHP OOP model with the number of footguns and WTF cases to rival magic=
<br>
&gt; quotes, register_globals=3Don and every other infamous gotcha we had i=
n the<br>
&gt; engine that got deleted out of existence.<br>
<br>
As someone who read the RFC like 20 times while it evolved (and just <br>
read it once more before submitting this email):<br>
<br>
Most of what the RFC spells out explicitly, because that&#39;s what RFCs <b=
r>
need to, is a pretty much natural consequence of how the existing PHP <br>
features work. You cannot really shorten the RFC without either making <br>
it underspecified or useless.<br>
<br>
Is there some syntax that could technically be omitted? Sure. Would <br>
doing so meaningfully simplify the RFC? No, because most of the text <br>
length comes from the interaction of existing syntax and semantics with <br=
>
hooks and thus is an inherent property of property hooks (pun not <br>
intended). It&#39;s not the RFCs fault that references exist, or that <br>
casting an object to an array is legal, or whatever else needs to be <br>
explicitly spelled out.<br>
<br>
I also believe that the chosen syntax fits nicely with the existing <br>
syntax, borrowing syntax where useful and inventing new syntax where the <b=
r>
existing syntax does not provide anything.<br>
<br>
It&#39;s a clear improvement over the status quo of __get() and __set(), <b=
r>
especially from a third-party tooling perspective. I&#39;m in favor.<br>
<br>
Best regards<br>
Tim D=C3=BCsterhus<br>
</blockquote></div><br clear=3D"all"><div>Yeah we had a discussion with Lar=
ry on SF Slack, he made some things clear that it&#39;s either all or nothi=
ng, because once they dove in, it became clear that there&#39;s no way to g=
radually to introduce it. So, if it passes, the community is just gonna hav=
e to deal with the massive scope of it if they want the hooks or forget abo=
ut them.</div><span class=3D"gmail_signature_prefix">-- </span><br><div dir=
=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div><br></div>Arv=C4=
=ABds Godjuks<div>+371 26 851 664</div><div><a href=3D"mailto:arvids.godjuk=
s@gmail.com" target=3D"_blank">arvids.godjuks@gmail.com</a></div><div>Teleg=
ram: @psihius=C2=A0<a href=3D"https://t.me/psihius" target=3D"_blank">https=
://t.me/psihius</a></div></div></div></div>

--000000000000a6a8400615c3bd7e--