Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120640
MIME-Version: 1.0
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>
 <64912532.6070809@adviesenzo.nl>
In-Reply-To: <64912532.6070809@adviesenzo.nl>
Date: Tue, 20 Jun 2023 10:59:12 +0200
Message-ID: <CAH5C8xUBPre_kUs3PChzD8AC01ZircP7BHHr6PAamx_BC_6ybQ@mail.gmail.com>
To: Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000001b8dde05fe8bdeb3"
Subject: Re: [PHP-DEV] [RFC] [Discussion] PHP 8.3 deprecations
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000001b8dde05fe8bdeb3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Juliette,

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.


Please note that Tim has just added a clarification regarding the removal o=
f
mt_rand():

For the Global Mersenne Twister specifically the removal will be left to an
> additional later vote,

allowing to defer the removal based on the remaining usage.
>

This means that mt_rand()  will most probably have a longer phasing out
period than normally, but at least
this buys us time to evaluate the timeframe of the removal. I hope that we
addressed your concerns.

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.
>

I don't think an impact analysis is useful all the time: sometimes because
it doesn't make much sense
*trying* to measure the impact of deprecating very rare or broken
functionality (e.g.
CRYPT_STD_* or the NumberFormatter::TYPE_CURRENCY constants). In other
cases, the analysis is
likely going to be misleading, since we don't have access to proprietary
code, and some functionality
is used in such code more often than in open-source projects (e.g. the
typical example is session-related
functions).


> 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.
>

Please let me clarify first that we do appreciate your dedication and
efforts a lot for maintaining such critical projects.
At the same time, - since PHP has almost 3 decades long of track record of
doing silly things -, we as maintainers
are also dedicated very much about improving our language and getting rid
of its unreliable/unexpected/unsafe behavior.

I also do believe that we do care about our users, and it's very rare that
some change is introduced without a heads up
multiple years before the removal. I know these deprecations and removals
usually feel like a burden for people who
tirelessly work on following these changes in their open-source projects in
their free time, but please do understand that
PHP would still be the same crazy language without the fundamental changes
which have been being introduced
in the recent years. We are happy to discuss the underlying problem
separately from this RFC, since the root cause
may be something else than the too many deprecations, starting from things
which we do not have control over (the underfincaning
of open source work) to other factors which we can control (e.g. the
minimum length of deprecation before
the removal, shorter/longer major version cycles, educating end-users to
use automation like Rector).

With all that said, we're going to start the vote on Thursday, since we do
believe the proposal is clear enough now, and
there's not much to discuss anymore.

Regards,
M=C3=A1t=C3=A9

--0000000000001b8dde05fe8bdeb3--