Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108032
To: George Peter Banyard <girgias@php.net>
References: <CAFPFaM+jztyaVeZ8WWa5WabkA7N1pf+D3-dhbAykgQQ14M07TQ@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <0c59dbea-2df6-d13d-e6f2-79495b6c1603@telia.com>
Date: Wed, 8 Jan 2020 13:22:44 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAFPFaM+jztyaVeZ8WWa5WabkA7N1pf+D3-dhbAykgQQ14M07TQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Adding TypeError and ValueError to count() function
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

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