> Terje Slettebø wrote: > > I'd say that's debatable. :) Yes, it can make it more convenient to handle > > data coming from outside the script (such as forms), but it can also hide > > bugs. While it can be argued that conversions between, say, arithmetic types > > (int and floats) may be useful, allowing conversion from something like NULL > > to empty string, integer 0, etc. (as PHP does) may be going a little over > > board, as an uninitialised variable (such as a member variable) may not be > > easily discovered. > > IMHO, that is covered by === and the NOTICE error level.
Scenario: --- Start --- class Something { public function __construct() { // Oops, forgot to initialise $this->something... } public function f() { return $this->something; } private $something; } error_reporting(E_ALL); $something=new Something; echo $something->f()+10; // Prints "10". --- End --- This will run without any notices, warnings or errors. If we meant to initialise Something::something to a value, then there's no way to detect that in f() (other than manual type-checking), since we can't specify the type for Something::f()'s return type. Had we been able to specify e.g. "int" as the return type, the call to Something::f() would give us an error message, alerting us to the problem. As the program stands, it has a silent bug... How would you solve this with === or E_ALL? Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php