Hey Larry,
On Sun, Jun 13, 2021, 20:46 Larry Garfield <larry@garfieldtech.com> wrote:
> I'm generally OK with it. The change makes sense.
>
> What I'm unclear on is why it's not including the actual deprecation. Not
> doing that yet and having it just become a noop first seems fine, but it's
> also clear that having it throw a deprecation in the future, and presumably
> then having those methods be removed outright, is the long-term plan. I'm
> good with that too, but I don't see why the full death-cycle isn't
> included, and half of it is instead punted to a future RFC.
>
Two reasons:
>
1. I don't see a removal of the methods as necessary at all anyway: while
they are no-op, removal increases the scope of the RFC too much, and it's
really not worth going there for the added work, when a further RFC would
make it more mechanical/isolated for 8.2+ and 9.0 afterwards. If the
methods survived in 9.0 too, it would be almost no impact anyway.
2. The usage of E_DEPRECATED inside php-src and in the composer ecosystem
at large irks me, a lot. Since we operate on a scripting language, we defer
things to the runtime, and by doing so we turn pure APIs into impure ones,
and lead to potential production disruption (happened to me multiple times,
precisely because of deprecations). I believe we don't have the right tools
to address deprecations upfront **yet**, and I'm mostly hoping for the
`#[Deprecated]` attribute to make its appearance before introducing yet
another harmful `trigger_error()` call. In this case, we have a clean cut
of API that can be **declared** deprecated, rather than turned into a
runtime problem: I want to see if the situation improves, before creating
new problems.
Would it help if I raised a second Draft RFC together with this one, so
that the promise of dealing with this later on is already fulfilled?
