On Wed, 28 Aug 2019 at 12:57, Nikita Popov <nikita....@gmail.com> wrote:
> However, I feel pretty strongly that converting any of these to > deprecations is not a good idea. While there's certainly different views on > this, I've seen it often enough deprecation warning are considered an even > lower error level than notices (imagine my surprise when PEAR stopped > working completely in PHP 8 because nobody ever saw the hundreds of > suppressed deprecations). We could throw a deprecation in addition, but I > think this will make the development experience really suck for anyone who > is not actively working on a migration right now (imagine seeing lots of > warnings/notices during development twice). > Again, I considered this carefully for undefined constants and discussed it extensively on the RFC and resulting thread. In short, "deprecation notice" doesn't have to mean "E_DEPRECATED". Arguably, "severity" and "type" should be two different dimensions, and E_DEPRECATION_WARNING would be E_DEPRECATION & E_WARNING; but in practice, a Warning containing the text "this is deprecated" achieves the goal just fine. Whatever the mechanism, the point is to make people aware as far in advance as possible, so that they can start addressing the problem before it becomes a blocker to upgrading. As briefly mentioned, third-party libraries are a key case here: if a library raises extra Warnings, I can take the time to submit a patch to that library, wait for the maintainer to accept it, and make sure I can use the latest version; if the library raises extra Errors, I have to delay my upgrade, or run a patched version of the library, until it's fixed. Regards, -- Rowan Tommins [IMSoP]
