Re: [PHP-DEV] RFC [Discussion]: array_find
Hi On 01.05.24 12:26, Larry Garfield wrote: This looks good to me, with one remaining exception, which isn't specific to this function but should still be discussed: Always passing the value and key to the callback is unsafe, for two reasons. 1. If the callback is an internal function rather than a user-land one, and it has only one argument, it will error confusingly. That makes the current implementation incompatible with unary built-in functions. See, for instance, https://www.php.net/is_string (and friends) I think, that this problem can easily be detected with static analysers. Currently neither PHPStan [1] nor psalm [2] does detect this issue, but as the tools already validate the signature (e.g. str_contains is rejected) this can probably be integrated and might even be considered a bug. The proper fix from PHP's side would be something like the proposal in https://externals.io/message/122928 (RFC idea: using the void type to control maximum arity of user-defined functions). 2. If the callback takes two arguments but the second is optional, it's highly unlikely that the key is the value expected as the second argument. This could lead to confusingly hilarious errors. See, for instance, https://www.php.net/intval. These won't come up in the typical case of passing an inline closure (either short or long form), but are still hidden landmines for anyone using functions not tailor made for these functions. I see the problem, but don't think, that this is a problem, that we can solve. As a note: Such problems exists in JavaScript, too [3] and is handled in the same way. I'm not sure of a good solution here, honestly, so I don't know what to recommend. In Crell/fp, I ended up just making two different versions of the function that pass one or two arguments. I don't think that's a good answer for this RFC, but I'm not sure what is. At the very least, it should be mentioned as a known-limitation that gets documented., unless we can come up with something better. I have added this problem in the section "Open Issues" in the RFC to document this behavior. [1] https://phpstan.org/r/bd0866cd-6a76-4c18-8eb3-0f3848de7f4a [2] https://psalm.dev/r/1baa3f8e0d [3] https://wirfs-brock.com/allen/posts/166
Re: [PHP-DEV] RFC [Discussion]: array_find
Hi On 19.04.24 23:29, Tim Düsterhus wrote:> Thinking about this: I believe that it would make sense to bundle array_any and array_every (or array_all, see below) within the same RFC due to the similarity. It can be a separate vote for those two, but having the option of getting all three would probably alleviate my concerns of adding new array functions piecemeal. The implementation should be trivial, because it effectively just changes the return type. Nevertheless I'm happy to assist should any issues arise. As for the naming: JavaScript: every + some Haskell : all + any Rust : all + any C++ : all_of + any_of + none_of Java : allMatch + anyMatch (in java.util.stream.Stream) Swift : allSatisfy + contains(where: …) It appears the commonly used choice is all + any. Thanks for your suggestion! I have added the `array_any` and `array_all` functions to the RFC accordingly. Cheers Josh
Re: [PHP-DEV] Re: Proposal to Create a MariaDB Alias for the MySQL PDO Driver
On Tuesday, 30 April 2024 at 22:33, Kamil Tekiela wrote: > I see absolutely no reason to do this. There is no difference between > MySQL and MariaDB in terms of PDO. Sure, the actual RDBMSs have > differences, but they play no role when it comes to PDO. > If MariaDB decides to change the protocol some day then we would need > a new driver to replace mysqlnd. Only then it would make sense to have > PDO_mariadb extension. But that is unlikely to happen any time soon. > The purpose of PDO subclasses is to offer driver specific > functionality and differentiate SQL syntax flavours. MariaDB and MySQL > use the same driver so they offer the same functionality and they use > the same SQL syntax (at least the parts that matter). And we must > remember that MariaDB is not the only MySQL-like DB out there. We are > not going to create a name alias for every possible fork of MySQL that > ever exists. It would be pointless. I agree with Kamil, MariaDB wanting to be incompatible with MySQL is their choice. If we introduce an "alias" and the MariaDB behaviour doesn't work, then we are on the hook to "fix" a database driver where we don't have the expertise. The MySQL driver is intended to only be used with a MySQL database, that it works with MariaDB is just a consequence of them forking from MySQL. And a user that uses a driver of a different DB than the one they run should expect incompatibilities. If there is a need for a MariaDB driver, then it should live outside the php-src repo, IMHO. We already have database drivers that are badly maintained because we don't have the expertise, or only recently acquired people that want to work on them. We removed the interbase and OCI8 extensions from php-src to PECL for this exact reason. Thus adding, effectively, a new database driver makes no sense to me. Best regards, Gina P. Banyard
Re: [PHP-DEV] RFC [Discussion]: array_find
On Tue, Apr 23, 2024, at 7:53 PM, Joshua Rüsweg wrote: > Hi > > On 19.04.24 21:20, Joshua Rüsweg wrote: >> I definitely see the point where there is an advantage to having two >> separate methods and can definitely understand that it is easier for >> developers to understand the control flow without evaluating the >> parameters. >> >> I'm unsure if that's really necessary though, because basically it's >> probably not necessary to directly see what exactly the function >> returns. Perhaps there will be another opinion on this in an email in >> the next few days. > > Now that I've thought about it for a few days, it's really better that > the whole thing is broken down into two methods. I have adjusted the RFC > accordingly. The RFC contains now two separat functions `array_find` and > `array_find_key`. > > Cheers > > Josh This looks good to me, with one remaining exception, which isn't specific to this function but should still be discussed: Always passing the value and key to the callback is unsafe, for two reasons. 1. If the callback is an internal function rather than a user-land one, and it has only one argument, it will error confusingly. That makes the current implementation incompatible with unary built-in functions. See, for instance, https://www.php.net/is_string (and friends) 2. If the callback takes two arguments but the second is optional, it's highly unlikely that the key is the value expected as the second argument. This could lead to confusingly hilarious errors. See, for instance, https://www.php.net/intval. These won't come up in the typical case of passing an inline closure (either short or long form), but are still hidden landmines for anyone using functions not tailor made for these functions. I'm not sure of a good solution here, honestly, so I don't know what to recommend. In Crell/fp, I ended up just making two different versions of the function that pass one or two arguments. I don't think that's a good answer for this RFC, but I'm not sure what is. At the very least, it should be mentioned as a known-limitation that gets documented., unless we can come up with something better. --Larry Garfield
[PHP-DEV] [RFC] [vote] Support object type in BCMath
Hi all! Voting for RFC: Support object type in BCMath has started. Voting ends on 2024-05-16 00:00 GMT. https://wiki.php.net/rfc/support_object_type_in_bcmath Regards, Saki
