Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120632
To: internals@lists.php.net,
 =?UTF-8?Q?kocsismate90@gmail.com_>>_M=c3=a1t=c3=a9_Kocsis?=
 <kocsismate90@gmail.com>
References: <CAH5C8xWAsRV+8h-tZ2Xq0=tn753kbSQX=KSEYsE2fWEtQVMrew@mail.gmail.com>
 <CAMs36HfmXuUJWJ0uih+Pj_vui4wG4vy3OTMmmspGmpP9h_gvgw@mail.gmail.com>
 <9ea3a5af-679d-ad63-f9c2-e0d8d148db3f@bastelstu.be>
 <CABTDVhDPLwBHDDzfXcHhs4VZNMHswWqum9muKgZcA63sgMCZdg@mail.gmail.com>
 <5ca4e382-8284-1cd0-696f-0dfd693523f8@bastelstu.be>
 <CAH5C8xWnAjep7kkTSg3=koBd7U0XuBkwF0-k61Mvv1J-m5yRiQ@mail.gmail.com>
 <648B24CF.4090105@adviesenzo.nl>
 <CAH5C8xWFOvBrEJbqB+cvHguyamQT6Kp=vLN3K-Nj9HyOgHx24w@mail.gmail.com>
Message-ID: <64912532.6070809@adviesenzo.nl>
Date: Tue, 20 Jun 2023 06:04:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <CAH5C8xWFOvBrEJbqB+cvHguyamQT6Kp=vLN3K-Nj9HyOgHx24w@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------080504070607070809060706"
Subject: Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

--------------080504070607070809060706
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 19-6-2023 23:27, Máté Kocsis wrote:
> Hi Juliette,
>
> For the mb_strimwidth() proposal an impact analysis is provided at the end
> ("over 100 projects were reviewed").
>
> For the other proposals there isn't and we do not believe this to be
> useful. We consider deprecations to be different from other RFCs that add
> new features,
> because functionality usually is deprecated because it is "harmful" in one
> way or another. A large impact (i.e. broad usage) should not necessarily be
> an
> argument against deprecation. Please also keep in mind that a deprecation
> is just that, a deprecation. It gives developers a heads up to migrate off
> the
> functionality at their own pace. We know that package maintainers are
> bugged by users whenever a new deprecation message emerges in a new PHP
> version,
> but this doesn't mean maintainers must react right away.
>
> Let us elaborate why we don't think impact analysis is needed here:
>
> * As per the TYPE_CURRENCY constant is (a) completely non-functional and
> (b) unfixable. As such any code that uses the constant is already broken and
> the deprecation is just pointing this out, making the user aware.
> * The CRYPT_* constants are possibly the least harmful part of the RFC, but
> they still can be misleading to a new developer. They are trivially
> polyfilled and
> also trivially removed from existing code by replacing them with 1.
> * MT_RAND_PHP is broken, because the sequences are not well-defined,
> defeating any reason for seeding. More reasons are already given in the RFC.
> * mt_rand() is everywhere and we don't believe anyone is denying that fact.
> But this should not be a reason against deprecation. As the RFC outlines,
> it is trivial to find this function misused with GitHub's search. We
> believe that the depreciation benefit outweighs the costs for existing
> users.
> * ldap_connect() is already soft-deprecated in the documentation.
>
> Regards,
> The authors of th RFC
>

Hi Máté,

While I appreciate that _most_ of these will be low impact and are 
justified, I very much disagree with that for the proposed `mt_rand()` 
and friends deprecations.

There are plenty of situations where it is of absolutely no interest to 
get a crypographically secure value, like for generating some 
semi-random test data and I strongly believe the impact of these 
deprecations to be large and fixing it won't always be trivial for 
codebases which support a range of PHP versions.

As a matter of principle I believe there should be an impact analysis 
for anything being deprecated. It can inform the voters as to the 
appropriateness of the timing of the deprecation - early on in a major 
cycle vs late in a major cycle -. Others may just take it as a FYI, but 
at least they have access to the information if they wanted to assess it.

While I appreciate what you are saying about deprecations being an 
"action list to migrate at your own pace", the reality for open source 
packages is different as the sheer amount of deprecations over the past 
few years have taken huge amounts of time to address and "leaving those 
till later" is just not an option as the amount of time needed is the 
same and time can only be spend once.

To give you some idea: work related to PHP 8.0 and 8.1 has been nine 
months out of the year for each in my case for the open source projects 
I'm involved with, so no, leaving that to later is not an option.

Smile,
Juliette


--------------080504070607070809060706--