Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123491
Precedence: bulk
MIME-Version: 1.0
References: <CAEPJdu=ZTyPQ3yabhOx=rxnv5niuA+9O4BP6EsvAdkZRSS5Q2g@mail.gmail.com>
 <CAJp_myWxSiNZD4e+h60SK09RrWzt0Du9Zjf68yRCQQU7S68JeA@mail.gmail.com> <CAPyj-LCtQxP5ODTuaDEypE3B1S5V8vWjth846AJm39QrLfi=5g@mail.gmail.com>
In-Reply-To: <CAPyj-LCtQxP5ODTuaDEypE3B1S5V8vWjth846AJm39QrLfi=5g@mail.gmail.com>
Date: Mon, 3 Jun 2024 11:03:28 -0500
Message-ID: <CAJp_myWdCHCzF6p0N3tG36D2SAm+2BJyhyus-T=0wCbS1Gddng@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Vote] #[\Deprecated] attribute
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000a23120619fe7af7"
From: mweierophinney@gmail.com ("Matthew Weier O'Phinney")

--0000000000000a23120619fe7af7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 3, 2024 at 9:46=E2=80=AFAM Ilija Tovilo <tovilo.ilija@gmail.com=
> wrote:

> Hi Matthew
>
> On Mon, Jun 3, 2024 at 3:15=E2=80=AFPM Matthew Weier O'Phinney
> <mweierophinney@gmail.com> wrote:
> >
> > On Wed, May 22, 2024 at 2:24=E2=80=AFAM Benjamin Au=C3=9Fenhofer <konta=
kt@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 m=
e
> 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.

>
>

--=20
Matthew Weier O'Phinney
mweierophinney@gmail.com
https://mwop.net/
he/him

--0000000000000a23120619fe7af7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jun 3, 2024 at 9:46=E2=80=AFA=
M Ilija Tovilo &lt;<a href=3D"mailto:tovilo.ilija@gmail.com">tovilo.ilija@g=
mail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">Hi Matthew<br>
<br>
On Mon, Jun 3, 2024 at 3:15=E2=80=AFPM Matthew Weier O&#39;Phinney<br>
&lt;<a href=3D"mailto:mweierophinney@gmail.com" target=3D"_blank">mweieroph=
inney@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Wed, May 22, 2024 at 2:24=E2=80=AFAM Benjamin Au=C3=9Fenhofer &lt;<=
a href=3D"mailto:kontakt@beberlei.de" target=3D"_blank">kontakt@beberlei.de=
</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; The vote for the RFC #[\Deprecated] attribute is now open:<br>
&gt;&gt;<br>
&gt;&gt; <a href=3D"https://wiki.php.net/rfc/deprecated_attribute" rel=3D"n=
oreferrer" target=3D"_blank">https://wiki.php.net/rfc/deprecated_attribute<=
/a><br>
&gt;&gt;<br>
&gt;&gt; Voting will close on Wednesday 5th June, 08:00 GMT.<br>
&gt;<br>
&gt; I have voted no for a few reasons:<br>
&gt;<br>
&gt; - Ideally, I&#39;d like to be able to mark _anything_ as deprecated. I=
n particular, not being able to mark a _class/interface/enum/etc_ as deprec=
ated makes this far less useful.<br>
<br>
While it&#39;s true that extending #[Deprecated] to classes would be<br>
useful, deprecation already exists as a language concept, and it can<br>
be extended to class-like structures without a BC break.<br></blockquote><d=
iv><br></div><div>Right, but I&#39;d rather have the ability to have it _no=
w_. It&#39;s far less often the case that I&#39;m deprecating a single meth=
od or constant, and more often the case that I&#39;m deprecating a class or=
 interface. Not having support for those immediately makes the feature=C2=
=A0 &quot;meh&quot; for me.</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">
<br>
&gt; - The &quot;since&quot; parameter is basically worthless to me. It&#39=
;s very easy to find out the last version that wasn&#39;t deprecated. What =
would be far more useful to a consumer is an argument indicating when somet=
hing will be removed (e.g. $toRemoveInVersion, $versionForRemoval, etc.). T=
his helps me as a user plan for the future.<br>
<br>
Did you vote yes in the secondary vote by accident? I voted no on the<br>
$since parameter for the same reason:<br>
<br>
* &quot;How long have I not fixed this?&quot; is not a particularly useful<=
br>
question to ask. &quot;When do I have to fix this?&quot; is more relevant.<=
br>
* The format of $since is intentionally left unstandardized, and it&#39;s<b=
r>
unclear (to me?) what it refers to. For example, some packages are<br>
split into multiple, smaller ones (e.g. Doctrine) with diverging<br>
version numbers. The sub-package version number may not be useful to<br>
the end-user, who never requires it directly. Similarly, referencing<br>
the main package version may be confusing, especially if the ranges of<br>
recent main and sub-package versions overlap.<br></blockquote><div><br></di=
v><div>I voted yes on it because it&#39;s not _worthless_, and if the RFC p=
asses, I&#39;d rather have it than not have it. But I agree that the lack o=
f a standard format for it, and the lack of a parallel &quot;will remove by=
&quot; argument make it far less useful.=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><br>
</blockquote></div><br clear=3D"all"><div><br></div><span class=3D"gmail_si=
gnature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><d=
iv dir=3D"ltr"><div>Matthew Weier O&#39;Phinney<br><a href=3D"mailto:mweier=
ophinney@gmail.com" target=3D"_blank">mweierophinney@gmail.com</a><br><a hr=
ef=3D"https://mwop.net/" target=3D"_blank">https://mwop.net/</a></div><div>=
he/him<br></div></div></div></div>

--0000000000000a23120619fe7af7--