On Mon, Jun 3, 2024 at 9:46 AM Ilija Tovilo <tovilo.il...@gmail.com> wrote:
> Hi Matthew > > On Mon, Jun 3, 2024 at 3:15 PM Matthew Weier O'Phinney > <mweierophin...@gmail.com> wrote: > > > > On Wed, May 22, 2024 at 2:24 AM Benjamin Außenhofer <kont...@beberlei.de> > 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. > Right, but I'd rather have the ability to have it _now_. It's far less often the case that I'm deprecating a single method or constant, and more often the case that I'm deprecating a class or interface. Not having support for those immediately makes the feature "meh" for me. > > > - 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. > I voted yes on it because it's not _worthless_, and if the RFC passes, I'd rather have it than not have it. But I agree that the lack of a standard format for it, and the lack of a parallel "will remove by" argument make it far less useful. > > -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
