Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127323
Precedence: bulk
MIME-Version: 1.0
References: <CALaXqqT1s3Qyhi0FEfybbycjefwUSuojENaU1owfUV_nMHxAog@mail.gmail.com>
 <5eebf119-aeff-4d1e-8f84-0e91f7c89bb4@gmail.com> <c3232274267ef2ca4d1833408e73c8c7@bastelstu.be>
In-Reply-To: <c3232274267ef2ca4d1833408e73c8c7@bastelstu.be>
Date: Thu, 8 May 2025 08:47:49 -0700
Message-ID: <CALaXqqT8aaJNQwxqgh4XUAVKYqrCz1iWmL6iLocWvSBDbsLVCA@mail.gmail.com>
Subject: Re: [PHP-DEV] Initial discussion - more deprecation options
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Niels Dossche <dossche.niels@gmail.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000bc0fc90634a1c740"
From: daniel.e.scherzer@gmail.com (Daniel Scherzer)

--000000000000bc0fc90634a1c740
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, May 8, 2025 at 8:38=E2=80=AFAM Tim D=C3=BCsterhus <tim@bastelstu.be=
> wrote:

> Hi
>
> Am 2025-05-07 21:43, schrieb Niels Dossche:
> > Definitely NAK on deprecating properties, which has the potential of
> > adding lots of overhead.
>
> FWIW: Deprecating properties is already possibly by means of deprecating
> a property hook. I guess this is an acceptable workaround to not require
> a dedicated support + associated complexity.
>
> see: https://3v4l.org/C6jRQ
>
>      class Foo
>      {
>          public string $foo
>          {
>              #[\Deprecated]
>              get {
>                  return $this->foo;
>              }
>
>              #[\Deprecated]
>              set {
>                  $this->foo =3D $value;
>              }
>          }
>      }
>
>      $f =3D new Foo();
>      $f->foo =3D 'dummy';
>      var_dump($f->foo);
>
>

So this example would emit deprecation warnings on all getting and setting
operations, but I was thinking that they would *not* be emitted when being
accessed from within the same class (private scope). Consider a project tha=
t
* does not want to use hooks (which add overhead)
* wants to support the deprecated behavior

It would then want to
* emit warnings when a property is accessed by protected/public scope
* but need to handle any writes from outside of the class by accessing the
property internally to see if the value changed

I'm not sure what NAK means in this context, but I think that allowing
`#[\Deprecated]` directly on the property instead of needing to use hooks
be done in the same way that the property hooks were implemented in terms
of dealing with VM handling and opcache, where things are not cached (I
assume, haven't looked into this enough, this is just a preliminary
discussion).

Allowing deprecation directly on properties would also be more performant
than needing to use hooks.

-Daniel

--000000000000bc0fc90634a1c740
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, May 8, 2025 at 8:38=E2=80=AFAM Ti=
m D=C3=BCsterhus &lt;<a href=3D"mailto:tim@bastelstu.be">tim@bastelstu.be</=
a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_container"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">Hi<br>
<br>
Am 2025-05-07 21:43, schrieb Niels Dossche:<br>
&gt; Definitely NAK on deprecating properties, which has the potential of <=
br>
&gt; adding lots of overhead.<br>
<br>
FWIW: Deprecating properties is already possibly by means of deprecating <b=
r>
a property hook. I guess this is an acceptable workaround to not require <b=
r>
a dedicated support + associated complexity.<br>
<br>
see: <a href=3D"https://3v4l.org/C6jRQ" rel=3D"noreferrer" target=3D"_blank=
">https://3v4l.org/C6jRQ</a><br>
<br>
=C2=A0 =C2=A0 =C2=A0class Foo<br>
=C2=A0 =C2=A0 =C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public string $foo<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0#[\Deprecated]<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0get {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return $this-=
&gt;foo;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0#[\Deprecated]<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0set {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0$this-&gt;foo=
 =3D $value;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0 =C2=A0 =C2=A0}<br>
<br>
=C2=A0 =C2=A0 =C2=A0$f =3D new Foo();<br>
=C2=A0 =C2=A0 =C2=A0$f-&gt;foo =3D &#39;dummy&#39;;<br>
=C2=A0 =C2=A0 =C2=A0var_dump($f-&gt;foo);<br><br></blockquote><div><br></di=
v><div><br></div><div>So this example would emit deprecation warnings on al=
l getting and setting operations, but I was thinking that they would *not* =
be emitted when being accessed from within the same class (private scope). =
Consider a project that</div><div>* does not want to use hooks (which add o=
verhead)</div><div>* wants to support the deprecated behavior</div><div><br=
></div><div>It would then want to</div><div>* emit warnings when a property=
 is accessed by protected/public scope</div><div>* but need to handle any w=
rites from outside of the class by accessing the property internally to see=
 if the value changed</div><div><br></div><div>I&#39;m not sure what NAK me=
ans in this context, but I think that allowing `#[\Deprecated]` directly on=
 the property instead of needing to use hooks be done in the same way that =
the property hooks were implemented in terms of dealing with=C2=A0VM handli=
ng and opcache, where things are not cached (I assume, haven&#39;t looked i=
nto this enough, this is just a preliminary discussion).</div><div><br></di=
v><div>Allowing deprecation directly on properties would also be more perfo=
rmant than needing to use hooks.</div><div><br></div><div>-Daniel=C2=A0=C2=
=A0</div></div></div>

--000000000000bc0fc90634a1c740--