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 w
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 RF
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 functio
Hi Tim,
On 15 June 2023 20:17:31 BST, "Tim Düsterhus" wrote:
>
>Agreed, this is not ideal to sell random_int() as the default choice for all
>things being equal. I've made an attempt for a more neutral / inclusive
>wording in https://github.com/php/doc-en/pull/2528.
In case it's a while befor
Hi
Thank you.
On 6/15/23 20:24, Rowan Tommins wrote:
Looping back to the beginning of my email: The recommended replacement
is random_int() which is available for years, but the "organic"
migration did not really work.
I think that's partly because, rightly or wrongly, random_int() is not
ge
On 15/06/2023 13:14, Tim Düsterhus wrote:
Looping back to the beginning of my email: The recommended replacement
is random_int() which is available for years, but the "organic"
migration did not really work.
I think that's partly because, rightly or wrongly, random_int() is not
generally vie
On 15-6-2023 9:18, Máté Kocsis wrote:
Hi everyone,
As there was no discussion and complaint for a long time, we would like to
move forward with the RFC. We believe Go and Tim answered Nikita's doubts
elaborately, so we should make the question decided during the vote.
Therefore, we'll start the
Hi
On 6/15/23 13:46, Rowan Tommins wrote:
While I agree with the logic of deprecating mt_rand() in general, I do
think it's too early to do so in 8.3. The Random extension is very new, and
To be clear: The recommended replacement for mt_rand() for the majority
of use cases / applications is r
On Thu, 15 Jun 2023 at 08:19, Máté Kocsis wrote:
> As there was no discussion and complaint for a long time, we would like to
> move forward with the RFC. We believe Go and Tim answered Nikita's doubts
> elaborately, so we should make the question decided during the vote.
>
While I agree with t
Hi everyone,
As there was no discussion and complaint for a long time, we would like to
move forward with the RFC. We believe Go and Tim answered Nikita's doubts
elaborately, so we should make the question decided during the vote.
Therefore, we'll start the vote on Monday, unless new problems eme
Hi
On 5/30/23 17:52, Go Kudo wrote:
> It should be deprecated with PHP 8.4 at the earliest to give folks at
least
Indeed, I agree that `lcg_value()` should be deprecated at least in PHP 8.4.
However, `lcg_value()` remains a dangerous function. It still has a weak
initial seeding problem (PID
2023年5月30日(火) 4:49 Tim Düsterhus :
> Hi
>
> On 5/29/23 08:44, Go Kudo wrote:
> > I realized I was about to add the deprecation of `lcg_value()` and forgot
> > to do so, so I added it.
> >
> > https://wiki.php.net/rfc/deprecations_php_8_3#global_combined_lcg
> >
> > As usual, my English is of low q
Hi
On 5/29/23 17:41, Nikita Popov wrote:
I don't think we should deprecate mt_rand().
There are plenty of use-cases that require neither a seedable (predictable) RNG
sequence, nor a cryptographically-secure RNG. For those use-cases (and
especially one-off uses), mt_rand() is perfect, and goin
Hi
On 5/29/23 08:44, Go Kudo wrote:
I realized I was about to add the deprecation of `lcg_value()` and forgot
to do so, so I added it.
https://wiki.php.net/rfc/deprecations_php_8_3#global_combined_lcg
As usual, my English is of low quality, so I would appreciate it if you
could point out any p
2023年5月30日(火) 0:42 Nikita Popov :
> On Mon, May 29, 2023, at 08:05, Máté Kocsis wrote:
> > Hi Everyone,
> >
> > Together with multiple authors, we'd like to start the discussion of the
> > usual
> > deprecation RFC for the subsequent PHP version. You can find the link
> below:
> > https://wiki.php
On Mon, May 29, 2023, at 08:05, Máté Kocsis wrote:
> Hi Everyone,
>
> Together with multiple authors, we'd like to start the discussion of the
> usual
> deprecation RFC for the subsequent PHP version. You can find the link below:
> https://wiki.php.net/rfc/deprecations_php_8_3
>
> Regards:
> Máté
I am not sure if others agree but in my opinion, Global Mersenne Twister
should have been a separate RFC. It has a discussion point that people
might want to discuss on mailing list first.
2023年5月29日(月) 15:05 Máté Kocsis :
> Hi Everyone,
>
> Together with multiple authors, we'd like to start the discussion of the
> usual
> deprecation RFC for the subsequent PHP version. You can find the link
> below:
> https://wiki.php.net/rfc/deprecations_php_8_3
>
> Regards:
> Máté Kocsis
>
Hi.
Hi Everyone,
Together with multiple authors, we'd like to start the discussion of the
usual
deprecation RFC for the subsequent PHP version. You can find the link below:
https://wiki.php.net/rfc/deprecations_php_8_3
Regards:
Máté Kocsis
19 matches
Mail list logo
