Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127305
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 7 May 2025 10:50:16 -0700
Message-ID: <CALaXqqT1s3Qyhi0FEfybbycjefwUSuojENaU1owfUV_nMHxAog@mail.gmail.com>
Subject: [PHP-DEV] Initial discussion - more deprecation options
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004f695d06348f5fb6"
From: daniel.e.scherzer@gmail.com (Daniel Scherzer)

--0000000000004f695d06348f5fb6
Content-Type: text/plain; charset="UTF-8"

Hi internals

I'd like to start off some preliminary discussion about expanding the places
that `#[\Deprecated]` can be used, and more widely how userland code can
have
the engine trigger deprecation warnings (rather than just manually calling
`trigger_error()`). This is intended to be a follow-up to the addition of
attributes on constants - it is now possible to use attributes so that the
engine emits warnings when

* Calling a function or method
* Accessing a class constant
* Accessing a global constant

My inspiration is MediaWiki's "Stable Interface Policy"[1] - there are some
things that MediaWiki (and other libraries) may want to deprecate, but that
do
not trigger deprecation warnings, or require work-arounds to trigger them
manually with `trigger_error()`. Specifically, I want to get the community's
thoughts on adding ways to

* Deprecate `use`ing traits
* Deprecate extending a class
* Deprecate overriding a method
* Deprecate implementing an interface
* Deprecate accessing a public/protected property
* Deprecate class aliases (maybe a new way to declare aliases with
`#[\ClassAlias]`?)

Having learned my lesson from the never-parameters RFC, I want to get a
sense
of support/opposition before spending time on the implementations. I also
want
a sense of which parts would need individual RFCs, and if those RFCs would
be
welcomed without first providing an implementation.

- Daniel

[1] https://www.mediawiki.org/wiki/Stable_interface_policy

--0000000000004f695d06348f5fb6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi internals</div><div><br></div>I&#39;d like to star=
t off some preliminary discussion about expanding the places<br>that `#[\De=
precated]` can be used, and more widely how userland code can have<br>the e=
ngine trigger deprecation warnings (rather than just manually calling<br>`t=
rigger_error()`). This is intended to be a follow-up to the addition of<br>=
attributes on constants - it is now possible to use attributes so that the<=
br>engine emits warnings when<br><br>* Calling a function or method<br>* Ac=
cessing a class constant<br>* Accessing a global constant<br><br>My inspira=
tion is MediaWiki&#39;s &quot;Stable Interface Policy&quot;[1] - there are =
some<br>things that MediaWiki (and other libraries) may want to deprecate, =
but that do<br>not trigger deprecation warnings, or require work-arounds to=
 trigger them<br>manually with `trigger_error()`. Specifically, I want to g=
et the community&#39;s<br>thoughts on adding ways to<br><br>* Deprecate `us=
e`ing traits<br>* Deprecate extending a class<br>* Deprecate overriding a m=
ethod<br>* Deprecate implementing an interface<br>* Deprecate accessing a p=
ublic/protected property<br>* Deprecate class aliases (maybe a new way to d=
eclare aliases with<br>`#[\ClassAlias]`?)<br><br>Having learned my lesson f=
rom the never-parameters RFC, I want to get a sense<br>of support/oppositio=
n before spending time on the implementations. I also want<br>a sense of wh=
ich parts would need individual RFCs, and if those RFCs would be<br>welcome=
d without first providing an implementation.<div><br></div><div>- Daniel<br=
><br>[1] <a href=3D"https://www.mediawiki.org/wiki/Stable_interface_policy"=
>https://www.mediawiki.org/wiki/Stable_interface_policy</a></div></div>

--0000000000004f695d06348f5fb6--