Initial discussion - more deprecation options

From: Date: Wed, 07 May 2025 17:50:16 +0000
Subject: Initial discussion - more deprecation options
Groups: php.internals 
Request: Send a blank email to internals+get-127305@lists.php.net to get a copy of this message
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 useing 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


Thread (7 messages)

« previous php.internals (#127305) next »