Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108079
MIME-Version: 1.0
References: <CAFPFaM+jztyaVeZ8WWa5WabkA7N1pf+D3-dhbAykgQQ14M07TQ@mail.gmail.com>
 <0c59dbea-2df6-d13d-e6f2-79495b6c1603@telia.com>
In-Reply-To: <0c59dbea-2df6-d13d-e6f2-79495b6c1603@telia.com>
Date: Thu, 9 Jan 2020 22:12:29 +0100
Message-ID: <CAFPFaMLMEsafWzyrUSr6rmjsnQf4NptdNtDW+64-9CvUagjZZQ@mail.gmail.com>
To: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000234267059bbb78dc"
Subject: Re: [PHP-DEV] Adding TypeError and ValueError to count() function
From: george.banyard@gmail.com ("G. P. B.")

--000000000000234267059bbb78dc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 8 Jan 2020 at 13:22, Bj=C3=B6rn Larsson <bjorn.x.larsson@telia.com>
wrote:

> 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=3D0; $i<count($blog_result); $i++){
>      $blog_result[$i]->nrOfComments =3D
> $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=C3=B6rn L
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

This is the purpose of keeping the behaviour of accepting null as a value
for count but deprecating it instead of flat out throwing a TypeError as a
TypeError should be thrown for clearly wrong values such as strings or
integers. This should ease the migration of code and allow another major
release cycle to convert to isset() and co.

Best regards

George P. Banyard

--000000000000234267059bbb78dc--