I am not convinced that making this an error is a good idea.
If I receive a $_GET/$_POST value that I expect to be a string value,
but I actually received an array, this would mean I need to now
explicitly check for it, since it will stop the runtime otherwise. Example:
http://home.sweet.home/list.php?cheese[]=brie&cheese[]=goat
Array
(
[cheese] => Array
(
[0] => brie
[1] => goat
)
)
That just makes it more verbose. An E_NOTICE is fine; it won't stop
anything, and it will show up in my error log. Another alternative I can
think of would be to throw an exception, since it's catchable. However,
we need to be aware that user input can generate this condition also,
and it shouldn't necessarily explode my process.
Just my 2 cents.
- M.
On 6/2/2011 10:17 AM, Alain Williams wrote:
On Thu, Jun 02, 2011 at 04:07:25PM +0200, Patrick ALLAERT wrote:
Not true. Here is a valid example that would break after implementing
this as en error.
if ("$x" == "Array") {
array_walk( $x, "print_r" );
}
I'm not saying that this is good code, I'm only saying that this would
break BC which is even worst.
....
Good point.
The real problem is that there are 2 sorts of PHP programmers.
1) those who will be grateful of anything that can help them find errors
in their code - these look at the error logs and correct their code.
2) those who write in a rush and as long as it appears to generate about
the right sort of results are happy, they don't care for anything else.
Unfortunately too many programmers are of type (2). They will bitch at what
they (in some ways rightly) see as a break in BC.
Maybe we ought to make it a warning for the PHP 5 series and an error for
PHP 6. Breaks in BC are more acceptable at major releases.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
