Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110066
MIME-Version: 1.0
References: <CAEPJdum26d_x6z2K4BFvRBXhNh8qQrh0tTE7wXzsfV7rwgm9Lg@mail.gmail.com>
 <CANaX5ncyFO9o7_z2n_ZsqVAzM7Qg6kxBWLqShWKS+1o=o6Fe+Q@mail.gmail.com>
 <CAEPJdu=MCYM5o-B96f6P+T7rCP+LqD5JCd=7M4SZ97MfxXoOBg@mail.gmail.com>
 <CANaX5nd1_LqD16U9m6aHpU0xbYF7Vs-vDFAHYdqxbq1O0WnY7w@mail.gmail.com>
 <CAEPJdu=zYc7T++4yiEqVwDUMqdYd6-LspF-n=3FxH2s=DzYNFw@mail.gmail.com> <CADyq6s+9LcBEtgVR7qhYPqbw3OsGCpUyE=Xr0e3juhJUuv9eVg@mail.gmail.com>
In-Reply-To: <CADyq6s+9LcBEtgVR7qhYPqbw3OsGCpUyE=Xr0e3juhJUuv9eVg@mail.gmail.com>
Date: Thu, 7 May 2020 12:18:55 +0200
Message-ID: <CAEPJdun8eJuLFck0anDKiXGKwGSBACmMw8OW16HtG8pnRnR0Rw@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: Davey Shafik <davey@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f12b7505a50c35fd"
Subject: Re: [PHP-DEV] [RFC] <<Deprecated>> Attribute
From: kontakt@beberlei.de (Benjamin Eberlei)

--000000000000f12b7505a50c35fd
Content-Type: text/plain; charset="UTF-8"

On Thu, May 7, 2020 at 10:54 AM Marco Pivetta <ocramius@gmail.com> wrote:

> Hey Benjamin,
>
> On Thu, May 7, 2020, 10:42 Benjamin Eberlei <kontakt@beberlei.de> wrote:
>
>>
>> This attribute is "reflected" by the engine during compilation, userland
>> doesn't have to reflect it again itself. on a code level the engine
>> "patches" each function automatically, this would do the following at
>> compile time:
>>
>> @@ -1,6 +1,6 @@
>>  <?php
>>
>> -<<Deprecated>>
>>  function foo() {
>> +    trigger_error('Function foo() is deprecated', E_USER_DEPRECATED);
>>      return 'foo';
>>  }
>>
>
> Already discussed it elsewhere, but I don't think that adding more runtime
> side-effects, especially on otherwise referentially transparent code, is a
> good idea.
>
> Very much against the current wave on `@trigger_error()` wave that symfony
> introduced. The rationale behind that hacky/messy approach is that
> sometimes deprecations are not determined statically (for example, if a
> specific parameter **value** is given), but I see no reason to do the same
> for static references.
>

While I agree with you on @trigger_errror, this is a seperate issue. PHP
itself triggers all its deprecations with trigger_error(..., E_DEPRECATED),
so this feature should do the same thing.

I started a discussion about how we can improve error handling in general
here: https://externals.io/message/110000 - first with some internal
changes. Based on that userland changes are the next thing that should
follow, but need a lot more care to avoid BC breaks.


> Since this would declare deprecations on static symbols, it can be
> detected statically, not at runtime.
>
> You will also get deprecations for very deeply nested components, which
> are transitive dependencies of what you effectively use in your sources:
> seen that in the wild already, and it wasn't a fun ride either.
>

Based on <<Deprecated>> there is at least the chance to avoid transitive
dependencies, that means preventing deprecation errors to get triggered,
when we are already in a deprecated function that triggered an error in the
stack above. but I haven't investigated this further yet.

>
> If you still want warnings at runtime, you can plug in something like
> GO-AOP-PHP, which kinda does exactly the same thing, but opt-in and not as
> a standardized side-effects engine (bad).
>

You can always disable this at runtime by removing E_USER_DEPRECATED from
error_reporting.

>
> Very similar PoV of Davey: since recently, we have the static analysis
> tools; let's endorse static analysis instead.
>
>>

--000000000000f12b7505a50c35fd--