> 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

Reply via email to