> 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