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
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 thecount()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 usecount()
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/4940Any 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
On Wed, 8 Jan 2020 at 13:22, Björn 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 thecount()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 usecount()
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/4940Any 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
--
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
On Wed, Jan 8, 2020 at 1:23 PM Björn 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 thecount()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 usecount()
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/4940Any 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
In the cases you encountered, do you know what type count() was used on?
Was it null? false? Or something else?
Nikita
Hi,
In the cases you encountered, do you know what type
count()was used on?
Was it null? false? Or something else?Nikita
we were in a similar boat as Björn to the point where we manually
patched PHP in production in order to not emit that warning so we
could update PHP while we were migrating the code-base. This made the
7.1 to 7.2 update the most painful update in the history of this
application (which was first released when 5.0.0 came out).
The most common case was count(null) which unfortunately was
happening all the time because of functions deciding to return an
array with elements or null if there was no elements to be found. Yes,
that's bad form, but hey - this is a nearly 20 years old application.
Of all the changes I've seen happening in PHP, this was the most painful.
Philip
Only lazy developers would complain about updating legacy code, perhaps the
code itself is worthless and need not be updated.
Then, what's the point of pursuing latest features or PHP version when a
individual or a company can't pursue code upgrade before version update?
On Tue, Jan 21, 2020, 8:41 PM Philip Hofstetter phofstetter@sensational.ch
wrote:
Hi,
In the cases you encountered, do you know what type
count()was used on?
Was it null? false? Or something else?Nikita
we were in a similar boat as Björn to the point where we manually
patched PHP in production in order to not emit that warning so we
could update PHP while we were migrating the code-base. This made the
7.1 to 7.2 update the most painful update in the history of this
application (which was first released when 5.0.0 came out).The most common case was
count(null)which unfortunately was
happening all the time because of functions deciding to return an
array with elements or null if there was no elements to be found. Yes,
that's bad form, but hey - this is a nearly 20 years old application.Of all the changes I've seen happening in PHP, this was the most painful.
Philip
Only lazy developers would complain about updating legacy code, perhaps
the code itself is worthless and need not be updated.Then, what's the point of pursuing latest features or PHP version when a
individual or a company can't pursue code upgrade before version update?
Please don't be rude.
Nikita
On Tue, Jan 21, 2020, 8:41 PM Philip Hofstetter phofstetter@sensational.ch
wrote:
Hi,
On Tue, Jan 21, 2020 at 6:17 PM Nikita Popov nikita.ppv@gmail.com
wrote:In the cases you encountered, do you know what type
count()was used on?
Was it null? false? Or something else?Nikita
we were in a similar boat as Björn to the point where we manually
patched PHP in production in order to not emit that warning so we
could update PHP while we were migrating the code-base. This made the
7.1 to 7.2 update the most painful update in the history of this
application (which was first released when 5.0.0 came out).The most common case was
count(null)which unfortunately was
happening all the time because of functions deciding to return an
array with elements or null if there was no elements to be found. Yes,
that's bad form, but hey - this is a nearly 20 years old application.Of all the changes I've seen happening in PHP, this was the most painful.
Philip
Den 2020-01-21 kl. 18:16, skrev Nikita Popov:
On Wed, Jan 8, 2020 at 1:23 PM Björn 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 thecount()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 usecount()
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
In the cases you encountered, do you know what type
count()was used on?
Was it null? false? Or something else?Nikita
It was null for in-house developed code. There is also an issue with
the Smarty count variable modifier, some work remains here.
It was developed using PHP 5.2 and today we run it on PHP 7.4. As
a side note the other most prevalent warning was:
- Creating default object from empty value in...
Due to code pattern below, with "new stdClass" missing: - $fields->content = isset($_POST['content']) ? $_POST['content'] : '';
r//Björn