Paragon Initiative Enterprises Security Team wrote on 9/2/21 15:25:> The
only question I have is: Should this land in 8.1 (it's small and
> self-contained) or 8.2?
>
8.1 is in feature freeze. Since this is adding functionality, it needs
to target 8.2.
Cheers,
Ben
signature.asc
Description:
Go Kudo wrote on 9/2/21 10:10:
> Hi Internals.
>
> Expanded from the previous RFC and changed it to an RFC that organizes the
> whole PHP random number generator. Also, the target version has been
> changed to 8.2.
>
> https://wiki.php.net/rfc/rng_extension
>
On Fri, 3 Sept 2021 at 18:41, Go Kudo wrote:
>
> Nikita wrote:
>> this one also moves all of the existing RNG-related functionality
>> from ext/standard to ext/random.
>
> There are several reasons for this.
>
> - The `random` extension name is already used by ext/standard and may
> interfere
On 9/2/21 5:10 PM, Go Kudo wrote:
Hi Internals.
Expanded from the previous RFC and changed it to an RFC that organizes the
whole PHP random number generator. Also, the target version has been
changed to 8.2.
https://wiki.php.net/rfc/rng_extension
https://github.com/php/php-src/pull/7453
Hello,
I would like to suggest a new PHP operator, which in my opinion PHP
needs to become more stricter.
At first, I invited nullish coalescing (??) operator, since it made my
code shorter and easier
to read. However, after some time, I realized that this is not a good
way to go, since it
This may not have been the best way to put it. The point I was trying to
make was that while BC Breaks do occur, they are very easy to solve.
The impact on downstream projects will be significant, and there may be
many extensions affected, since this change concerns a frequently used RNG
feature.
Indeed, it may be true that these suggestions should not be made all at
once. If necessary, I would like to propose to organize the RNG
implementation first.
Do we still need an RFC in this case? I'm not sure I'm not fully understand
the criteria for an RFC. Does this internal API change count as
David Kolář wrote on 9/4/21 17:19:
> Back to the suggestion - I suggest creating a new IFNULL operator, which
> will simply test if
> expression is null. If not, it returns left-hand part, if yes, it
> returns right-hand part.
This is already what the `??` operator does. For example:
Well, yes, but not exactly.
What I dislike on ?? operator is, that it supress all warnings in the
expression - in my opinion it shares the same
issue as @ operator and why people discourage other to use it - because
it may supress far more errors than you want
to supress. And this is the case
Thanks marc.
> "shuffleString()" works on byte level and so it should be
"shuffleBytes()".
Hmm. This may be a difficult problem related to the PHP language
specification. As with `str_shuffle()`, most people will probably use it to
shuffle strings. People who want to shuffle binaries are likely
On Fri, Sep 3, 2021 at 10:51 PM Hans Henrik Bergan wrote:
> PS i've seen *HORRIBLE* fs performance for php-running-on-windows,
> where the same filesystem operations on the same files took like 5 seconds
> on linux-running-on-vmware-on-laptop-running-windows-10, versus several
> minutes for the
11 matches
Mail list logo
