Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123402
Precedence: bulk
MIME-Version: 1.0
References: <CAEPJdu=ZTyPQ3yabhOx=rxnv5niuA+9O4BP6EsvAdkZRSS5Q2g@mail.gmail.com>
 <CAOWwgpkni4fHgZ0=AywFy=5ZrzD2o+i-xWfvK__fifo8UUQQ4w@mail.gmail.com> <d829484b-cb81-4bf3-87ea-4d83658f4b3c@processus.org>
In-Reply-To: <d829484b-cb81-4bf3-87ea-4d83658f4b3c@processus.org>
Date: Wed, 22 May 2024 11:23:19 +0300
Message-ID: <CAL0xaBF_55n4RhAiwbqoFZ1yUqPFLcppJg3QtPrRmVSQDqxtyw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Vote] #[\Deprecated] attribute
To: Pierre <pierre-php@processus.org>
Cc: Nicolas Grekas <nicolas.grekas+php@gmail.com>, 
	=?UTF-8?Q?Benjamin_Au=C3=9Fenhofer?= <kontakt@beberlei.de>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cdadf8061906a7ca"
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--000000000000cdadf8061906a7ca
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 22 May 2024 at 11:01, Pierre <pierre-php@processus.org> wrote:

> Le 22/05/2024 =C3=A0 09:33, Nicolas Grekas a =C3=A9crit :
>
> Hi Benjamin,
>
> 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 voted "no" because I think this is better addressed in userland, as thi=
s
> gives more flexibility.
> I would better have an attribute that is made only for static analysis
> with no runtime side effects at all.
> Being forced to make the attribute final because the implementation in th=
e
> engine requires is an example of why the engine is not the correct place =
to
> send this notice. Another example is not being able to add the attribute =
on
> classes because [engine reasons].
>
> trigger_error() is better fitted for the runtime side-effect when it's
> desired.
> In my opinion, #[Deprecated] should be only for static analysers /
> reflection (although this would need another discussion - I'm not sure th=
is
> would benefit being in the engine vs in a userland package.
>
> Thanks for the RFC anyway.
>
> Nicolas
>
> I'm always dubious when I read the "this can be addressed or better
> addressed in userland": as soon as you need something as little as the
> Deprecated attribute, if it's not in core but in userland, you encounter
> two very serious issues: first one, fragmentation, every framework,
> organisation, or static analysis tool will have its own variant, second o=
ne
> if the community converges toward a single one, you then will be dependen=
t
> on a certain framework or huge tooling.
>
> I can see many benefits in having this in core, one being that every
> static analyzer will implement it using the core attribute, so any projec=
t
> and developer using it can choose any static analysis tooling without
> having to change or adapt its code everywhere, or learning a different
> convention in order to use different tools.
>
> That's my 2 cents, but the "better in userland" argument seems to me
> almost always biased or wrong. Especially for this Deprecated argument,
> this a very common need, and each project Doctrine, Symfony, any tool
> implement it in a different manner. I don't want to be rude, but as a
> developer using all of those, it's very annoying having to learn differen=
t
> ways of doing something as simple and naive that saying that a function i=
s
> deprecated. One manner is sufficient, even if not perfect.
>
> --
>
> Pierre
>
Hello everyone.

I have to agree with Pierre on this one as a userland developer.
To give a good illustration: Guzzle. I'm trying to get rid of it in my code
base and use SF HttpClient (mostly for the sole reason that guzzle
truncates replies in their exceptions without any ability to configure that
and cutting off all actually useful information about why request failed)
and... I can't... Because some other package is hardwired to Guzzle and
refuses any attempts to inject a different HttpClient. Which forces me to
roll my own implementations, thankfully making API clients is fairly simple=
.
A Deprecated attribute belongs in the core.

--=20

Arv=C4=ABds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius

--000000000000cdadf8061906a7ca
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 Wed, 22 May 2024 at 11:01, Pierre =
&lt;<a href=3D"mailto:pierre-php@processus.org">pierre-php@processus.org</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-left:1ex"><u>=
</u>

 =20
   =20
 =20
  <div>
    <div>Le 22/05/2024 =C3=A0 09:33, Nicolas Grekas a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr">
        <div dir=3D"ltr">Hi Benjamin,<br>
        </div>
        <br>
        <div class=3D"gmail_quote">
          <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div dir=3D"ltr">The vote for the RFC #[\Deprecated]
              attribute=C2=A0is now open:<br>
              <br>
              <a href=3D"https://wiki.php.net/rfc/deprecated_attribute" tar=
get=3D"_blank">https://wiki.php.net/rfc/deprecated_attribute</a><br>
              <br>
              Voting will close on Wednesday 5th June, 08:00 GMT.<br>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>I voted &quot;no&quot; because I think this is better addres=
sed in
            userland, as this gives more flexibility.</div>
          <div>I would better have an attribute that is made only for
            static analysis with no runtime side effects at all.</div>
          <div>Being forced to make the attribute final because the
            implementation in the engine requires is an example of why
            the engine is not the correct place to send this notice.
            Another example is not being able to add the attribute on
            classes because [engine reasons].<br>
          </div>
          <div><br>
          </div>
          <div>trigger_error() is better fitted for the runtime
            side-effect when it&#39;s desired.</div>
          <div>In my opinion, #[Deprecated] should be only for static
            analysers / reflection (although this would need another
            discussion - I&#39;m not sure this would benefit being in the
            engine vs in a userland package.</div>
          <div><br>
          </div>
          <div>Thanks for the RFC anyway.</div>
          <div><br>
          </div>
          <div>Nicolas<br>
          </div>
        </div>
      </div>
    </blockquote>
    <p>I&#39;m always dubious when I read the &quot;this can be addressed o=
r
      better addressed in userland&quot;: as soon as you need something as
      little as the Deprecated attribute, if it&#39;s not in core but in
      userland, you encounter two very serious issues: first one,
      fragmentation, every framework, organisation, or static analysis
      tool will have its own variant, second one if the community
      converges toward a single one, you then will be dependent on a
      certain framework or huge tooling.</p>
    <p>I can see many benefits in having this in core, one being that
      every static analyzer will implement it using the core attribute,
      so any project and developer using it can choose any static
      analysis tooling without having to change or adapt its code
      everywhere, or learning a different convention in order to use
      different tools.<br>
    </p>
    <p>That&#39;s my 2 cents, but the &quot;better in userland&quot; argume=
nt seems to
      me almost always biased or wrong. Especially for this Deprecated
      argument, this a very common need, and each project Doctrine,
      Symfony, any tool implement it in a different manner. I don&#39;t wan=
t
      to be rude, but as a developer using all of those, it&#39;s very
      annoying having to learn different ways of doing something as
      simple and naive that saying that a function is deprecated. One
      manner is sufficient, even if not perfect.<br>
    </p>
    <p>--</p>
    <p>Pierre<br>
    </p>
  </div>

</blockquote></div>Hello everyone.<div><br></div><div>I have to agree with =
Pierre on this one as a userland developer.=C2=A0</div><div>To give a good =
illustration: Guzzle. I&#39;m trying to get rid of it in my code base and u=
se SF HttpClient (mostly for the sole reason that guzzle truncates replies =
in their exceptions without any ability to configure that and cutting off a=
ll actually useful information about why request failed) and... I can&#39;t=
... Because some other package is hardwired to Guzzle and refuses any attem=
pts to inject a different HttpClient. Which forces me to roll my own implem=
entations, thankfully making API clients is fairly simple.</div><div>A Depr=
ecated attribute belongs in the core.=C2=A0<br clear=3D"all"><div><br></div=
><span class=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" clas=
s=3D"gmail_signature"><div dir=3D"ltr"><div><br></div>Arv=C4=ABds Godjuks<d=
iv>+371 26 851 664</div><div><a href=3D"mailto:arvids.godjuks@gmail.com" ta=
rget=3D"_blank">arvids.godjuks@gmail.com</a></div><div>Telegram: @psihius=
=C2=A0<a href=3D"https://t.me/psihius" target=3D"_blank">https://t.me/psihi=
us</a></div></div></div></div></div>

--000000000000cdadf8061906a7ca--