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/4572
Hi,
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
