Hello internals,
i would like to change foreach a tiny bit. Actually i don't like the
warning when using foreach with null.
marcus@zaphod /usr/src/php-cvs $ php -r '$n=NULL; foreach($n as $v);'
make: `sapi/cli/php' is up to date.
Warning: Invalid argument supplied for foreach() in Command line code on line 1
marcus@zaphod /usr/src/php-cvs $ php -r 'foreach(NULL as $v);'
make: `sapi/cli/php' is up to date.
Warning: Invalid argument supplied for foreach() in Command line code on line 1
The way we use NULL
in PHP should result in no warning here. The patch for
this can be found here:
http://php.net/~helly/php/ext/ze2/ze2-foreach-null-20051025.diff.txt
It was made with head but applies to 5.1 as well.
Any opinions?
Best regards,
Marcus
I'd say silently ignoring it and moving along is fine here.
Only if the var IS_NULL, but this is the case.
So I'm +1.
Hello internals,
i would like to change foreach a tiny bit. Actually i don't like the
warning when using foreach with null.marcus@zaphod /usr/src/php-cvs $ php -r '$n=NULL; foreach($n as $v);'
make: `sapi/cli/php' is up to date.Warning: Invalid argument supplied for foreach() in Command line code on line 1
marcus@zaphod /usr/src/php-cvs $ php -r 'foreach(NULL as $v);'
make: `sapi/cli/php' is up to date.Warning: Invalid argument supplied for foreach() in Command line code on line 1
The way we use
NULL
in PHP should result in no warning here. The patch for
this can be found here:
http://php.net/~helly/php/ext/ze2/ze2-foreach-null-20051025.diff.txt
It was made with head but applies to 5.1 as well.Any opinions?
--
Wbr,
Antony Dovgal
+1 as well if and only if this applies to IS_NULL
I'd say silently ignoring it and moving along is fine here.
Only if the var IS_NULL, but this is the case.So I'm +1.
Hello internals,
i would like to change foreach a tiny bit. Actually i don't like the
warning when using foreach with null.marcus@zaphod /usr/src/php-cvs $ php -r '$n=NULL; foreach($n as $v);'
make: `sapi/cli/php' is up to date.Warning: Invalid argument supplied for foreach() in Command line code on line 1
marcus@zaphod /usr/src/php-cvs $ php -r 'foreach(NULL as $v);'
make: `sapi/cli/php' is up to date.Warning: Invalid argument supplied for foreach() in Command line code on line 1
The way we use
NULL
in PHP should result in no warning here. The patch for
this can be found here:
http://php.net/~helly/php/ext/ze2/ze2-foreach-null-20051025.diff.txt
It was made with head but applies to 5.1 as well.Any opinions?
--
Wbr,
Antony Dovgal
Marcus Boerger wrote:
i would like to change foreach a tiny bit. Actually i don't like the
warning when using foreach with null.
Marcus, you already know my feelings on this one.
+1
Rob
Will the patch make it silently ignore also empty string and 0?
If not, -1. (what's with null being suddenly equal to empty array? :)
--Jani
Hello internals,
i would like to change foreach a tiny bit. Actually i don't like the
warning when using foreach with null.marcus@zaphod /usr/src/php-cvs $ php -r '$n=NULL; foreach($n as $v);'
make: `sapi/cli/php' is up to date.Warning: Invalid argument supplied for foreach() in Command line code on line 1
marcus@zaphod /usr/src/php-cvs $ php -r 'foreach(NULL as $v);'
make: `sapi/cli/php' is up to date.Warning: Invalid argument supplied for foreach() in Command line code on line 1
The way we use
NULL
in PHP should result in no warning here. The patch for
this can be found here:
http://php.net/~helly/php/ext/ze2/ze2-foreach-null-20051025.diff.txt
It was made with head but applies to 5.1 as well.Any opinions?
Best regards,
Marcus
--
Give me your money at @ http://pecl.php.net/wishlist.php/sniper
Donating money may make me happier and friendlier for a limited period!
Death to all 4 letter abbreviations starting with P!
It currently is equal:
$ php -r 'var_dump(null == array()); var_dump((array) null);'
bool(true)
array(0) {
}
Ants
Jani Taskinen wrote:
Will the patch make it silently ignore also empty string and 0?
If not, -1. (what's with null being suddenly equal to empty array? :)--Jani
Hello internals,
i would like to change foreach a tiny bit. Actually i don't like the
warning when using foreach with null.marcus@zaphod /usr/src/php-cvs $ php -r '$n=NULL; foreach($n as $v);'
make: `sapi/cli/php' is up to date.Warning: Invalid argument supplied for foreach() in Command line code
on line 1
marcus@zaphod /usr/src/php-cvs $ php -r 'foreach(NULL as $v);'
make: `sapi/cli/php' is up to date.Warning: Invalid argument supplied for foreach() in Command line code
on line 1The way we use
NULL
in PHP should result in no warning here. The patch
for
this can be found here:
http://php.net/~helly/php/ext/ze2/ze2-foreach-null-20051025.diff.txt
It was made with head but applies to 5.1 as well.Any opinions?
Best regards,
Marcus
It currently is equal:
$ php -r 'var_dump(null == array()); var_dump((array) null);'
bool(true)
array(0) {
}
No, there aren't equal.
Use === and you'll see the difference.
--
Wbr,
Antony Dovgal
Antony Dovgal wrote:
It currently is equal:
$ php -r 'var_dump(null == array()); var_dump((array) null);'
bool(true)
array(0) {
}No, there aren't equal.
Use === and you'll see the difference.
At least the manual says that the == operator is named equal and the ===
operator is named identical. Actually I wanted to point out that null is
a bit of a special case in PHP:
$ php -r 'var_dump(null == 0); var_dump(null == array()); var_dump(0 ==
array());'
bool(true)
bool(true)
bool(false)
$ php -r 'var_dump((array) ""); var_dump((array) 0); var_dump((array)
null);'
array(1) {
[0]=>
string(0) ""
}
array(1) {
[0]=>
int(0)
}
array(0) {
}
+-0 on the foreach issue, but with the SPL Iterators I can see where
Marcus is coming from.
Ants
Ants Aasma wrote:
+-0 on the foreach issue, but with the SPL Iterators I can see where
Marcus is coming from.
Ok, I can see the reason behind it now as casting to array is not an
option for objects with SPL Iterators. One little side-note: Programmers
will still have to do an if($obj) check if they use $obj for just about
anything but foreach.
After thinking it over you convinced me that treating null (and only
null) like an empty array in foreach() might be a good idea, probably
even for the non-SPL case.
- Chris
Hello Christian,
Tuesday, October 25, 2005, 7:28:09 PM, you wrote:
Ants Aasma wrote:
+-0 on the foreach issue, but with the SPL Iterators I can see where
Marcus is coming from.
Ok, I can see the reason behind it now as casting to array is not an
option for objects with SPL Iterators. One little side-note: Programmers
will still have to do an if($obj) check if they use $obj for just about
anything but foreach.
After thinking it over you convinced me that treating null (and only
null) like an empty array in foreach() might be a good idea, probably
even for the non-SPL case.
Hey you two guys pointed out the reason very exactly! Only the usecase
wasn't SPL but a potential change i want to do in SimpleXML and the reson
SXE behaves like it currently does. But yes SPL and PDO would probably
benefit in the same way.
Best regards,
Marcus
Marcus Boerger wrote:
i would like to change foreach a tiny bit. Actually i don't like the
warning when using foreach with null.The way we use
NULL
in PHP should result in no warning here. The patch for
Can you elaborate on the "The way we use NULL
in PHP" part?
IMPW (In my PHP world) null represents an undefined variable. Trying to
iterate over it could be a programming mistake. Like iterating over a
scalar value. I normally use foreach ((array)$var as $value) if $var is
of "mixed" type which also catches null. But most of the time I'm more
comfortable with making sure I provide a real array in all cases and
don't rely on magic.
Just my two cents,
- Chris
IMHO this is a bad idea, if you really wanted to support NULL
in a
particular case you, as a developer could do:
php -r '$n=NULL; foreach((array)$n as $v);'
Making NULL
usage transparent where array is expects will lead to
difficult to debug code.
-1 for removing the warning.
Ilia
Ilia Alshanetsky wrote:
IMHO this is a bad idea, if you really wanted to support
NULL
in a
particular case you, as a developer could do:
php -r '$n=NULL; foreach((array)$n as $v);'Making
NULL
usage transparent where array is expects will lead to
difficult to debug code.
hi :-)
the warning for foreach() in this case seems to be inconsistent with:
php -r '$a = null; $b = array(); var_dump((empty($a) === empty($b)), (count($a) === count($b)));'
which gives no warnings or otherwise, also as a lesser developer than you I don't
buy the notion that dropping the warning makes debugging more difficult because
advanced code should be checking vars properly before using them and, well,
for any given foreach loop there is often enough an 'if (!count($array))'-like
statement to take care of the 'empty' case. and in cases when speed is very important
it saves an explicit cast (is that more expensive anyway?) and it means not requiring
an '@' to suppress which I do know is more expensive than not having any E_* to suppress at all.
on the face of it I understand begin against, feedback is good.
but removing the warning would make the engine behaviour just a little
more consistent - which is nice, no?
function(MyCLass $x = null) {}
which was nice from the start fom a user perspective,
I was puzzled as to why it went, glad it came back and
hope it says :-)
</sidenote>
thanks for php, and kind regards in general,
jochem
-1 for removing the warning.
Ilia
advanced code should be checking vars properly before using them and, well,
for any given foreach loop there is often enough an 'if (!count($array))'-like
statement to take care of the 'empty' case. and in cases when speed is very
important
..and where `count()` magically returns 1 f.e. for FALSE. :)
So really you can't rely on that. :)
--Jani
Jani Taskinen wrote:
advanced code should be checking vars properly before using them and,
well,
for any given foreach loop there is often enough an 'if
(!count($array))'-like
statement to take care of the 'empty' case. and in cases when speed is
very important..and where `count()` magically returns 1 f.e. for FALSE. :) So really you can't rely on that. :)
true - although personally I always do if(is_array($r) && count($r)) in such cases.
so it seems that there is inconsistency regardless of
whether the warning is removed or not.
out of interest what are the ramifications for SPL and simpleXML
if the warning is not dropped?
--Jani
Hello Jochem,
Thursday, October 27, 2005, 12:49:57 PM, you wrote:
Jani Taskinen wrote:
advanced code should be checking vars properly before using them and,
well,
for any given foreach loop there is often enough an 'if
(!count($array))'-like
statement to take care of the 'empty' case. and in cases when speed is
very important..and where `count()` magically returns 1 f.e. for FALSE. :) So really you can't rely on that. :)
true - although personally I always do if(is_array($r) && count($r)) in such cases.
so it seems that there is inconsistency regardless of
whether the warning is removed or not.
out of interest what are the ramifications for SPL and simpleXML
if the warning is not dropped?
Right now ther is no place in SPL that would benefit. But both SXE and PDO
have to create empty instances to allow code that does not need further
cehecks before sending to foreach(). So the idea is actually some speed
improvement and in case of SimpleXML i'd like to be able to check existance
of a sub element by the following: !is_null($sxe->element)
Best regards,
Marcus
I think we should be keeping the warning (i.e. -1 for the change).
I don't see a reason why overloaded objects can't expose an API of an
empty array() instead of changing this behavior to fit the
implementation. But even if it weren't so, there has to be a good
reason to change the general case.
Andi
IMHO this is a bad idea, if you really wanted to support
NULL
in a
particular case you, as a developer could do:
php -r '$n=NULL; foreach((array)$n as $v);'Making
NULL
usage transparent where array is expects will lead to
difficult to debug code.-1 for removing the warning.
Yes, I agree, we should not remove this warning.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
IMHO this is a bad idea, if you really wanted to support
NULL
in a
particular case you, as a developer could do:
php -r '$n=NULL; foreach((array)$n as $v);'Making
NULL
usage transparent where array is expects will lead to
difficult to debug code.-1 for removing the warning.
Yes, I agree, we should not remove this warning.
Derick
+1 on not removing the warning. I can't see any reson why it should be
removed.
php -r '$foo = array(2, 3, 4); echo substr("foobar", $foo). "\n";'
currently prints "oobar". Would like to see, as Jani suggested, E_STRICT
notice thrown when wrong data type is passed to a function/language
construct.
- Hannes
IMHO this is a bad idea, if you really wanted to support
NULL
in a
particular case you, as a developer could do:
php -r '$n=NULL; foreach((array)$n as $v);'Making
NULL
usage transparent where array is expects will lead to
difficult to debug code.-1 for removing the warning.
Yes, I agree, we should not remove this warning.
+1 on not removing the warning. I can't see any reson why it should be
removed.
Erm, that's what I meant. +1 with not is the same as -1 without....
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org