Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123091
Precedence: bulk
MIME-Version: 1.0
References: <CAPyj-LBMQEJ=2BF=xk_on4O2xTU+MM2XRAZ5g=uPwVOf=bh+sw@mail.gmail.com>
In-Reply-To: <CAPyj-LBMQEJ=2BF=xk_on4O2xTU+MM2XRAZ5g=uPwVOf=bh+sw@mail.gmail.com>
Date: Wed, 10 Apr 2024 16:56:56 +0200
Message-ID: <CAOWwgpns2OcJeocDB66JNw9tmgm_WqCoN9Y7_UGuLmnMyC8phA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Vote announcement] Property hooks
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a75c920615bf40d2"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000a75c920615bf40d2
Content-Type: text/plain; charset="UTF-8"

Hi Ilija, Larry,

Heads-up: Larry and I would like to start the vote of the property
> hooks RFC tomorrow:
> https://wiki.php.net/rfc/property-hooks
>

I would make 3 changes to the RFC if I were in charge :

   - I'd make $this->propName inside a hook access the parent property via
   its hooks if any. I'd do this because that'd provide
   encapsulation-by-default for inheritance. Aka a parent class could
   reasonably expect its child classes to get through its hooks. (I'd be fine
   with only allowing the "=" operator on this.)
   - I'd keep the special $field value to access the backing value. It's a
   clear way to signify that accessing the raw value is possible only in
   hooks, never in other methods.
   - And I'd consider forbidding any method calls in hooks except static
   methods. This would allow factorising functional logic without opening for
   side-effects on the object outside of hooks themselves.

I'm sharing this in case it rings a bell somewhere, but I can work with the
peculiarities of the current RFC and I must admit I didn't spend as much
time as you on the topic so my proposals might fall short, while yours to
actually work. Thanks for that :)

I'm in favor of the RFC.

Cheers,
Nicolas

--000000000000a75c920615bf40d2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Ilija, Larry,<br></div><br><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Heads-up: Larry and I would like to start the vote of the property<br>
hooks RFC tomorrow:<br>
<a href=3D"https://wiki.php.net/rfc/property-hooks" rel=3D"noreferrer" targ=
et=3D"_blank">https://wiki.php.net/rfc/property-hooks</a><br></blockquote><=
div><br></div><div>I would make 3 changes to the RFC if I were in charge :<=
/div><ul><li>I&#39;d make $this-&gt;propName inside a hook access the paren=
t property via its hooks if any. I&#39;d do this because that&#39;d provide=
 encapsulation-by-default for inheritance. Aka a parent class could reasona=
bly expect its child classes to get through its hooks. (I&#39;d be fine wit=
h only allowing the &quot;=3D&quot; operator on this.)<br></li><li>I&#39;d =
keep the special $field value to access the backing value. It&#39;s a clear=
 way to signify that accessing the raw value is  possible only in hooks, ne=
ver in other methods.</li><li>And I&#39;d consider forbidding any method ca=
lls in hooks except static methods. This would allow factorising functional=
 logic without opening for side-effects on the object outside of hooks them=
selves.</li></ul><div>I&#39;m sharing this in case it rings a bell somewher=
e, but I can work with the peculiarities of the current RFC and I must admi=
t I didn&#39;t spend as much time as you on the topic so my proposals might=
 fall short, while yours to actually work. Thanks for that :)<br></div><div=
><br></div><div>I&#39;m in favor of the RFC.</div><div><br></div><div>Cheer=
s,</div><div>Nicolas<br></div></div></div>

--000000000000a75c920615bf40d2--