Hi Matthew
On Mon, Jun 3, 2024 at 3:15 PM Matthew Weier O'Phinney
<[email protected]> wrote:
>
> On Wed, May 22, 2024 at 2:24 AM Benjamin Außenhofer <[email protected]> wrote:
>>
>> The vote for the RFC #[\Deprecated] attribute is now open:
>>
>> https://wiki.php.net/rfc/deprecated_attribute
>>
>> Voting will close on Wednesday 5th June, 08:00 GMT.
>
> I have voted no for a few reasons:
>
> - Ideally, I'd like to be able to mark _anything_ as deprecated. In particular, not being
> able to mark a _class/interface/enum/etc_ as deprecated makes this far less useful.
While it's true that extending #[Deprecated] to classes would be
useful, deprecation already exists as a language concept, and it can
be extended to class-like structures without a BC break.
> - The "since" parameter is basically worthless to me. It's very easy to find out
> the last version that wasn't deprecated. What would be far more useful to a consumer is an
> argument indicating when something will be removed (e.g. $toRemoveInVersion, $versionForRemoval,
> etc.). This helps me as a user plan for the future.
Did you vote yes in the secondary vote by accident? I voted no on the
$since parameter for the same reason:
* "How long have I not fixed this?" is not a particularly useful
question to ask. "When do I have to fix this?" is more relevant.
* The format of $since is intentionally left unstandardized, and it's
unclear (to me?) what it refers to. For example, some packages are
split into multiple, smaller ones (e.g. Doctrine) with diverging
version numbers. The sub-package version number may not be useful to
the end-user, who never requires it directly. Similarly, referencing
the main package version may be confusing, especially if the ranges of
recent main and sub-package versions overlap.
Ilija
> - The "since" parameter is basically worthless to me. It's very easy to find out
> the last version that wasn't deprecated. What would be far more useful to a consumer is an
> argument indicating when something will be removed (e.g. $toRemoveInVersion, $versionForRemoval,
> etc.). This helps me as a user plan for the future.
>
> --
> Matthew Weier O'Phinney
> [email protected]
> https://mwop.net/
> he/him