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
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
[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
Jani Taskinen 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
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 aE_NOTICEis more
appropriate thanE_STRICT- you should only be usingcount()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
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 aE_NOTICEis more
appropriate thanE_STRICT- you should only be usingcount()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
- useless -
count()provides no useful information about strings - 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
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 aE_NOTICEis more
appropriate thanE_STRICT- you should only be usingcount()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