Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124690
Message-ID: <7f787046-17e8-4272-bd00-074fc21b9808@bastelstu.be>
Date: Tue, 30 Jul 2024 21:20:24 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.4
To: "Christoph M. Becker" <cmbecker69@gmx.de>,
 "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, internals@lists.php.net
References: <USzt7tZZlO1DmAbSTLhD-bqa23FqZn0zk2aah8Ndxgk9c7RY5PefQ8MjbYPUYAzr2_m4Cf-5AI4PuNBTS84rim_FNS6RaT-cWSv714HEvvU=@gpb.moe>
 <1a88918e-e808-d778-45e1-53797660e093@php.net>
 <CAPrKfG5Cw_nU7g7FR+t4C1-YZ8CDsDO_-sRs=yEsHO5kCTZL+A@mail.gmail.com>
 <95147d9d-d6e8-4396-bf0b-409c33679f90@bastelstu.be>
 <CAPrKfG4TijmZ_N9512_Fk9MBUNg=E6PjNTy-bCbV8CAj9_wX8A@mail.gmail.com>
 <CAPrKfG7Hi0SGbLA31V-9KjHM50QaX+Q=PptuO4+VMOrz7d9eBA@mail.gmail.com>
 <G9IiDe18a2ZhrXPA-zljNZsawKCZxlTn2ACfJpM32scdRkRflZ2rM6Ra8z88ZYDczomex4pffxZMpVhEjdB74YQXXNyqJkd7rQdDGA14HC0=@gpb.moe>
 <89096756-9f50-4b10-9630-d3b18e4b9c29@gmx.de>
 <d54b99fd-64ea-40f2-9fee-c904f1305893@app.fastmail.com>
 <3beb3488-94fc-484e-ac6c-ce7a7a0facd2@app.fastmail.com>
 <921dcf17-280b-4005-b31f-5811dbe5ce62@gmx.de>
Content-Language: en-US
In-Reply-To: <921dcf17-280b-4005-b31f-5811dbe5ce62@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 7/27/24 13:24, Christoph M. Becker wrote:
> Hmm, such soft deprecations should be a good thing, but I'm afraid they
> are not really reaching much of the user base.  Remember ext/mysql?
> That was soft deprecated for "centuries", but still support channels
> were burning when it actually had been deprecated, and even after it had
> been removed.  (interestingly <https://pecl.php.net/package/mysql> still
> says the package would have been moved to <http://php.net/mysql>)

What prevented me personally from adding a "soft deprecation" to the 
documentation is, that the function is not actually deprecated and not 
slated for deprecation. It is not up to me to decide to soft deprecate 
something.

And regarding your remark of not reaching folks, I agree. uniqid()'s 
documentation is already full of warnings, but folks still reach for it.

> Maybe, just maybe, it might be a good idea to repurpose E_STRICT for
> such things.  Basically a three step deprecation: first document that a
> feature is obsolete, then trigger E_STRICT, and only then E_DEPRECATED.
> I haven't really thought this through, though.

I've proposed a deprecation instead of any other error level, because it 
is the least severe error level we have available: Libraries and 
Frameworks nowadays generally understand that deprecations are not hard 
errors and thus do not convert these to exceptions, but instead just 
direct them to a different log file / show them in the framework's 
debugging toolkit.

Best regards
Tim Düsterhus