Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123400
Content-Type: multipart/alternative;
 boundary="------------K5SYDt0Mq3CwBD09Jk0Y3xRC"
Message-ID: <d829484b-cb81-4bf3-87ea-4d83658f4b3c@processus.org>
Date: Wed, 22 May 2024 10:00:26 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] [Vote] #[\Deprecated] attribute
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>,
 =?UTF-8?Q?Benjamin_Au=C3=9Fenhofer?= <kontakt@beberlei.de>
Cc: PHP Internals <internals@lists.php.net>
References: <CAEPJdu=ZTyPQ3yabhOx=rxnv5niuA+9O4BP6EsvAdkZRSS5Q2g@mail.gmail.com>
 <CAOWwgpkni4fHgZ0=AywFy=5ZrzD2o+i-xWfvK__fifo8UUQQ4w@mail.gmail.com>
Content-Language: fr-FR, en-US
In-Reply-To: <CAOWwgpkni4fHgZ0=AywFy=5ZrzD2o+i-xWfvK__fifo8UUQQ4w@mail.gmail.com>
From: pierre-php@processus.org (Pierre)

This is a multi-part message in MIME format.
--------------K5SYDt0Mq3CwBD09Jk0Y3xRC
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Le 22/05/2024 à 09:33, Nicolas Grekas a écrit :
> 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 
> this 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 
> 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].
>
> 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 
> this 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 
one if the community converges toward a single one, you then will be 
dependent 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 
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.

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 
different ways of doing something as simple and naive that saying that a 
function is deprecated. One manner is sufficient, even if not perfect.

--

Pierre

--------------K5SYDt0Mq3CwBD09Jk0Y3xRC
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Le 22/05/2024 à 09:33, Nicolas Grekas a
      écrit :<br>
    </div>
    <blockquote type="cite"
cite="mid:CAOWwgpkni4fHgZ0=AywFy=5ZrzD2o+i-xWfvK__fifo8UUQQ4w@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">Hi Benjamin,<br>
        </div>
        <br>
        <div class="gmail_quote">
          <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div dir="ltr">The vote for the RFC #[\Deprecated]
              attribute is now open:<br>
              <br>
              <a href="https://wiki.php.net/rfc/deprecated_attribute"
                target="_blank" moz-do-not-send="true"
                class="moz-txt-link-freetext">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 "no" because I think this is better addressed 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's desired.</div>
          <div>In my opinion, #[Deprecated] should be only for static
            analysers / reflection (although this would need another
            discussion - I'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'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 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'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 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>
  </body>
</html>

--------------K5SYDt0Mq3CwBD09Jk0Y3xRC--