Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127309
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 07 May 2025 14:37:04 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <006dd0fd-06ca-4339-a6a2-3897926512f4@app.fastmail.com>
In-Reply-To: 
 <CALaXqqT1s3Qyhi0FEfybbycjefwUSuojENaU1owfUV_nMHxAog@mail.gmail.com>
References: 
 <CALaXqqT1s3Qyhi0FEfybbycjefwUSuojENaU1owfUV_nMHxAog@mail.gmail.com>
Subject: Re: [PHP-DEV] Initial discussion - more deprecation options
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, May 7, 2025, at 12:50 PM, Daniel Scherzer wrote:
> 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

I am in favor of expanding the deprecation attribute to more places.  I believe the ask previously (when the attribute was first introduced) was to keep it in sync with C-level deprecations.  Viz, being able to deprecate an interface should be added for both C code and user-space code at the same time, so they're parallel.  I think that is a reasonable requirement, and any RFCs on the topic should follow that recommendation.

RFCs can be proposed regardless of implementation status.  Technically the rules allow the to be voted on and even approved without a patch, but I believe that is generally regarded as uncooth, at best, as implementation details can often dictate design.  (Absolutely true for much of the stuff Ilija and I work on.)  I think the de facto rule is probably "you can talk about anything, but don't call a vote without at least a mostly-working patch that people have reviewed."

--Larry Garfield