Everything

php

Re: foreach with null

php.internals

sebastian

20 years ago

> Any opinions?

Good code is code that's easy to debug (among other things). By
removing the "Invalid argument supplied for foreach()" warning without
providing mechanisms to turn it on, debugging code will be more
difficult. Logically speaking, when does it make sense to iterate over
something that isn't an array?

If I were writing one-time use scripts that I will never use again
(not likely) this might be desired behavior. If I were writing code
that is used by other programmers, paying users, and under conditions
likely to change (implying changing code, and often debugging and
testing), the ability to detect errors as early as possible is vital
(The Pragmatic Programmer is a good reference for this). Most people
don't want to spend more time than is necessary to troubleshoot code.
Probably more importantly, managers and customers don't want to wait
longer for a product they're paying for.

Understandly, PHP aims to be "easy" in so many ways, but I believe in
order for PHP to survive in the enterprise and allow users to easily
write good code, it *must* support such features. Without features
like these, writing PHP won't be so easy because the work required to
do the checking is forced on the programmer.

The "Invalid argument supplied for foreach()" warning should not be
removed unless it can be done without breaking compatibility and with
a way to optionally turn it on/off. I think we can learn a good lesson
from Perl on this one. Here is how we turn on/off warnings, lexically:

use warnings;

- sebastian

Markus Fischer

20 years ago

Sebastian wrote:

> Good code is code that's easy to debug (among other things). By
> removing the "Invalid argument supplied for foreach()" warning without
> providing mechanisms to turn it on, debugging code will be more
> difficult. Logically speaking, when does it make sense to iterate over
> something that isn't an array?
>
> If I were writing one-time use scripts that I will never use again
> (not likely) this might be desired behavior. If I were writing code
> that is used by other programmers, paying users, and under conditions
> likely to change (implying changing code, and often debugging and
> testing), the ability to detect errors as early as possible is vital
> (The Pragmatic Programmer is a good reference for this). Most people
> don't want to spend more time than is necessary to troubleshoot code.
> Probably more importantly, managers and customers don't want to wait
> longer for a product they're paying for.

I also don't feel very comfortable with silencing the warning for NULL.
If the variable is not an array and not traversable there's nothing to
iterate over and it should tell the user. If we intentionally want to
not know about this error, an alternate syntax with the '@' operator
should be considered as it was requested in the past, e.g. '@foreach' or
'foreach(@$notarrayOrIterable ...'.

- Markus

Jani Taskinen

20 years ago

On Wed, 26 Oct 2005, Sebastian wrote:

[clip]

> Good code is code that's easy to debug (among other things). By
> removing the "Invalid argument supplied for foreach()" warning without
> providing mechanisms to turn it on, debugging code will be more
> difficult.

[clip]

You got to the point here. I'd like to see E_STRICT be used for this
if this NULL thing is accepted. Also, I found out recently something
that I didn't know about before and which I count as inconsistent:

count(<somethingthatisnotanemptyarraynorobjectnornull>) returns int(1).

It would be nice that count() would also produce an E_STRICT notice
when passed something else than object or array. Or rather make
every single function and language construct to produce the E_STRICT
notice when passed wrong type of variable.

--Jani

Greg Beaver

20 years ago

Jani Taskinen wrote:

> On Wed, 26 Oct 2005, Sebastian wrote:
>
> [clip]
>
>> Good code is code that's easy to debug (among other things). By
>> removing the "Invalid argument supplied for foreach()" warning without
>> providing mechanisms to turn it on, debugging code will be more
>> difficult.
>
> [clip]
>
>     You got to the point here. I'd like to see E_STRICT be used for this
>     if this NULL thing is accepted. Also, I found out recently something
>     that I didn't know about before and which I count as inconsistent:
>
>     count(<somethingthatisnotanemptyarraynorobjectnornull>) returns int(1).
>
>     It would be nice that count() would also produce an E_STRICT notice
>     when passed something else than object or array. Or rather make
>     every single function and language construct to produce the E_STRICT
>     notice when passed wrong type of variable.

amen, this behavior makes no sense even though sizeof() is an alias to
count().  sizeof('this') and sizeof('this long thing') are both 1, which
makes no sense.  I would go so far as to say a E_NOTICE is more
appropriate than E_STRICT - you should only be using count() for
arrays/objects.

Then Zend could remove the silly question from the cert example exam ;).

Greg

Ilia A.

20 years ago

Greg Beaver wrote:

> amen, this behavior makes no sense even though sizeof() is an alias to
> count().  sizeof('this') and sizeof('this long thing') are both 1, which
> makes no sense.  I would go so far as to say a E_NOTICE is more
> appropriate than E_STRICT - you should only be using count() for
> arrays/objects.

Actually this result makes perfect sense since type conversion changes
string into array('your string') and does a count of that, which is 1.

Ilia

Greg Beaver

20 years ago

Ilia Alshanetsky wrote:

> Greg Beaver wrote:
>
>>amen, this behavior makes no sense even though sizeof() is an alias to
>>count().  sizeof('this') and sizeof('this long thing') are both 1, which
>>makes no sense.  I would go so far as to say a E_NOTICE is more
>>appropriate than E_STRICT - you should only be using count() for
>>arrays/objects.
>
>
> Actually this result makes perfect sense since type conversion changes
> string into array('your string') and does a count of that, which is 1.

Yes, it makes sense from this perspective, but from a real-life
programming perspective it is

1) useless - count() provides no useful information about strings
2) potentially buggy.

For instance, PEAR's XML_Unserializer (XML_Serializer package)
represents XML elements with simple text node children as a string, and
tags with anything else (attributes, child elements) as an array.
Improperly written code that uses count() without checking is_array()
would happily run with no warning whatsoever.  However, imho it would
make PHP more robust if the logical error condition were also a language
error, that's all.

Greg

Jani Taskinen

20 years ago

On Wed, 26 Oct 2005, Ilia Alshanetsky wrote:

>
> Greg Beaver wrote:
>> amen, this behavior makes no sense even though sizeof() is an alias to
>> count().  sizeof('this') and sizeof('this long thing') are both 1, which
>> makes no sense.  I would go so far as to say a E_NOTICE is more
>> appropriate than E_STRICT - you should only be using count() for
>> arrays/objects.
>
> Actually this result makes perfect sense since type conversion changes
> string into array('your string') and does a count of that, which is 1.

This is yet another magic type casting I'd like to get rid of..
Strict is not always bad, mmkay? :)

I got bitten by this (unexpected?) behaviour of count() myself this week.
I must have been strict in my mind and not passed anything but arrays
to it before this. :)

--Jani