# foreach with null

- Thread: https://externals.io/message/19728
- Original archive: https://news-web.php.net/php.internals/19728
- Started by Sebastian on 2005-10-26T17:18:12+00:00
- Messages: 7
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #19728 — Sebastian — 2005-10-26T17:18:12+00:00

URL: https://externals.io/message/19728#19728

> 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

---

## #19730 — Markus Fischer — 2005-10-26T17:50:40+00:00

URL: https://externals.io/message/19728#19730 · In reply to: #19728

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

---

## #19740 — Jani Taskinen — 2005-10-26T19:36:48+00:00

URL: https://externals.io/message/19728#19740 · In reply to: #19728

[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

---

## #19741 — Greg Beaver — 2005-10-26T19:42:57+00:00

URL: https://externals.io/message/19728#19741 · In reply to: #19740

Jani Taskinen wrote:
> 
> 
> [clip]
> 
> > […]
> 
> [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

---

## #19743 — Ilia Alshanetsky — 2005-10-26T21:24:36+00:00

URL: https://externals.io/message/19728#19743 · In reply to: #19741

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

---

## #19751 — Greg Beaver — 2005-10-26T23:17:11+00:00

URL: https://externals.io/message/19728#19751 · In reply to: #19743

Ilia Alshanetsky wrote:
> Greg Beaver wrote:
> 
> > […]
> 
> 
> 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

---

## #19757 — Jani Taskinen — 2005-10-27T10:10:20+00:00

URL: https://externals.io/message/19728#19757 · In reply to: #19743

>
> Greg Beaver wrote:
> > […]
>
> 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