On Thu, May 7, 2020 at 10:54 AM Marco Pivetta <ocram...@gmail.com> wrote:
> Hey Benjamin,
>
> On Thu, May 7, 2020, 10:42 Benjamin Eberlei <kont...@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.
>
>>
