Re: Adding TypeError and ValueError to count() function
| From: | Björn Larsson | Date: | Wed, 08 Jan 2020 12:22:44 +0000 |
| Subject: | Re: Adding TypeError and ValueError to count() function | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-108032@lists.php.net to get a copy of this message | ||
Den 2020-01-07 kl. 21:57, skrev George Peter Banyard:
Greetings internals, I would like your input on adding TypeError and ValueError exceptions to the count() function in respect to the Consistent type errors for internal functions RFC [1], the initial PR [2] was denied as null was not accepted as a value when it seems to be prevalent to use count() as a substitute for isset() (this is currently done in the test runner for php-src), although a "type error" warning was already emitted with null. So I've made an adjustment by still accepting null but deprecating it's usage. An other option is to allow null as a value that always return 0. I've also added a ValueError exception on invalid modes. The new pull request is located at https://github.com/php/php-src/pull/4940 Any comments would be appreciated. Best regards and happy new year. George Peter Banyard [1] https://wiki.php.net/rfc/consistent_type_errors [2] https://github.com/php/php-src/pull/4572Hi, My take on this is that when converting a legacy code base from PHP 5.2 to PHP 7.4, the RFC Counting of non-countable objects generated quite a lot of hassle. Count was used for checking return of DB values. Code piece could e.g. look like: for($i=0; $i<count($blog_result); $i++){
$blog_result[$i]->nrOfComments = $blog->getNumberOfComments($blog_result[$i]->id);} If I read this correctly, with warnings today as is, the code after will continue, but with exception I presume execution will stop (unless I catch it of course). I still have warnings to weed out from legacy code but also from Smarty library. So I wonder what impact this change will have? I mean, I can live with the warnings fixing code bit by bit... r//Björn L