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.
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.
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).
Very similar PoV of Davey: since recently, we have the static analysis
tools; let's endorse static analysis instead.
>
