[PHP-DEV] Re: Sodium - Stream Counter API
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: OpenPGP digital signature
[PHP-DEV] Re: [RFC] Random Extension 3.0
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 > https://github.com/php/php-src/pull/7453 > > Hopefully you will get some good responses. > > Regards, > Go Kudo > This proposal seems like two different proposals to me: - The first consolidates and cleans up RNG functions for internals - The second exposes an OOP API for working with RNGs Personally, I don't see the benefit of including this OOP API in the core. I don't think it provides any benefits over similar abstractions in userland, and in fact, I think this kind of API is best suited for iteration in userland. Cheers, Ben signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Random Extension 3.0
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 with the build system. > - Due to the namespace rules for new extensions, it is inappropriate to > rename an extension. > - Due to history, the rand / mt_rand dependency is tricky and I thought it > was time to sort it out. > - I don't think it's a good idea to have multiple header files for a single > domain feature. Have you considered how much work that is going to incur on downstream projects? If there's a good reason for moving stuff around then it can be appropriate, but the RFC phrasing of: "At the same time, the following internal APIs will also be relocated. If you want to use them, you can _simply_ include ext/random/random.h." sounds pretty dismissive of causing possibly unneeded work for downstream projects. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Random Extension 3.0
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 Hopefully you will get some good responses. For me (user land developer with no voting power) your RFC looks pretty :) Beside the abstract vs interface question I have some other notes: On the one hand you define "getBytes()" which returns a string and on the other hand you define "shuffleString()" - is the first one a binary string and the other a charset dependent string? I guess here "shuffleString()" works on byte level and so it should be "shuffleBytes()". Why are there no default values for min/max on "getInt()" - It seems unnecessary to me to pass min/max arguments if you are just interested in a random integer or passing max as well if you are interested in a positive integer only. Thanks for the nice RFC! Regards, Go Kudo Marc
[PHP-DEV] New operator suggestion
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 makes my code much less strict. The nullish coalescing function is what I need, however what I don't want in some cases is its error suppression function. Here is an example I use a lot while generating forms: I have ?? operator here, mainly because prop2 can be undefined, but in a lot of cases I know that prop1 exists, or at least $var. Issue is, that there is no error outputted even when $var is undefined and I missed such errors a lot. In my opinion is not good to learn people to suppress whatever error might occur in the whole expression. 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. A suggested token for such operator is "??:" as a mix between "??" and "?:" tokens. Basically elvis token "?:" but with strict comparison to null, instead of loose comparison to false. With new suggested operator a safe way to write expression above, where I only expect prop2 to be undefined would look like this: $var->prop1?->prop2 ??: ''; Notice, that use of newer operator "?->" really fits here. It clearly marks, what I expect to be undefined and "??:" operator just takes the role of converting possible "null" into and empty string. What do you think about this? Is it worth to introduce this new operator to promote more strictness of PHP? Is it worth to create an RFC for this? I never did an RFC yet and has not much experience with C++, since I am mostly Delphi/PHP/JS developer, but I might try. Still, I would appreciate a help from someone willing and experienced in RFC creation. Thank you in advance for your opinions, David Kolář -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Random Extension 3.0
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. However, in other words, it may need to be sorted out as soon as possible. However, I also understand the theory that this should be done in conjunction with a major language change. Perhaps I should have suggested this for PHP 8.0. Either way, I'll try to separate these suggestions if necessary, but if we were to try to provide an OOP API without BC Break, what do you think would be the ideal form? Regards, Go Kudo 2021年9月5日(日) 4:24 Dan Ackroyd : > 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 with the build system. > > - Due to the namespace rules for new extensions, it is inappropriate to > > rename an extension. > > - Due to history, the rand / mt_rand dependency is tricky and I thought > it > > was time to sort it out. > > - I don't think it's a good idea to have multiple header files for a > single > > domain feature. > > Have you considered how much work that is going to incur on downstream > projects? > > If there's a good reason for moving stuff around then it can be > appropriate, but the RFC phrasing of: "At the same time, the > following internal APIs will also be relocated. If you want to use > them, you can _simply_ include ext/random/random.h." sounds pretty > dismissive of causing possibly unneeded work for downstream projects. > > cheers > Dan > Ack >
Re: [PHP-DEV] Re: [RFC] Random Extension 3.0
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 a BC Break that requires an RFC? > Personally, I don't see the benefit of including this OOP API in the core. On the other hand, can you tell me why you thought it was unnecessary? Was my example unrealistic? I'm sorry if my English is not good and my writing seems offensive. I have no intention to do so. Regards, Go Kudo 2021年9月5日(日) 1:12 Ben Ramsey : > 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 > > https://github.com/php/php-src/pull/7453 > > > > Hopefully you will get some good responses. > > > > Regards, > > Go Kudo > > > > > This proposal seems like two different proposals to me: > > - The first consolidates and cleans up RNG functions for internals > - The second exposes an OOP API for working with RNGs > > Personally, I don't see the benefit of including this OOP API in the > core. I don't think it provides any benefits over similar abstractions > in userland, and in fact, I think this kind of API is best suited for > iteration in userland. > > Cheers, > Ben > >
[PHP-DEV] Re: New operator suggestion
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: https://3v4l.org/RlDjK Are you suggesting that it should emit a warning if `$var` is undefined, as it does in this case? https://3v4l.org/aZAj0 Cheers, Ben signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: New operator suggestion
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 with $var->prop1->prop2 - when I expect just prop2 being undefined, it supresses even error of undefined $var, which might not be intentional and I miss that error because of that. So suggested ??: operator should behave like ??, but without the supression mechanic - just short hand for "$x === null ? $x : expr" instead of "isset($x) ? $x : expr". The 2nd case you wrote is actually even weird to me - I am not sure at all if PHP should behave like that. Because in your example, when $var is undefined: $var->prop1->prop2 ?? '' does not emit any error, because ?? supresses them $var?->prop1?->prop2 ?? '' does emit error - which is weird, since ?-> is still wrapped under ??, so I am not sure why error shows here. Anyway what I want is emitting error on undefined $var and undefined prop1, but NOT undefined prop2, when: $var->prop1?->prop2 ??: '' Do you get it? Just a shorthand for this: $var->prop1?->prop2 === null ? $var->prop1->prop2 : ''; Which any of suggested current solutions can't do. David On 05.09.2021 0:42, Ben Ramsey wrote: 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: https://3v4l.org/RlDjK Are you suggesting that it should emit a warning if `$var` is undefined, as it does in this case? https://3v4l.org/aZAj0 Cheers, Ben -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Random Extension 3.0
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 to understand that in PHP it is synonymous with `shuffleBytes()`. > Why are there no default values for min/max on "getInt()" - It seems unnecessary to me to pass min/max arguments My apologies. I completely forgot that I needed this. Add this along with a fix for the RNG\NumberGenerator implementation. Regards, Go Kudo 2021年9月5日(日) 5:57 Marc : > > 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 > > > > Hopefully you will get some good responses. > > For me (user land developer with no voting power) your RFC looks pretty :) > > Beside the abstract vs interface question I have some other notes: > > On the one hand you define "getBytes()" which returns a string and on > the other hand you define "shuffleString()" - is the first one a binary > string and the other a charset dependent string? I guess here > "shuffleString()" works on byte level and so it should be "shuffleBytes()". > > Why are there no default values for min/max on "getInt()" - It seems > unnecessary to me to pass min/max arguments if you are just interested > in a random integer or passing max as well if you are interested in a > positive integer only. > > Thanks for the nice RFC! > > > Regards, > > Go Kudo > Marc >
Re: [PHP-DEV] Adding a way to disable the stat cache
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 same operation on the same laptop on windows 10 directly.. Amusingly Windows FS performance made emigrating easier for me. I've never used or coded on Windows, but one of the job offers I got when I was emigrating back in 1998 was a Word doc. To read it I ran it through strings on Solaris and that's when I discovered Word saves diffs. To read my offer letter I had to reconstruct the previous five offer letters so I had a good view of what compensation was. >From talking to Windows people I learned it did diffs due to FS performance. Which seemed like an amusing solution to a problem. Kevin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
