Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25673
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain broadpark.no from 80.202.4.58 cause and error)
Date: Wed, 13 Sep 2006 21:11:55 +0200
To: Brian Moon <brianm@dealnews.com>
Cc: RQuadling@GoogleMail.com, Marcus Boerger <helly@php.net>,
 internals@lists.php.net
Message-ID: <005301c6d768$7a5fb0e0$9a02a8c0@pc>
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: 8BIT
References: <0a1301c6d64f$8af01c70$a900000a@adstate.local>
 <74293252.20060912230042@marcus-boerger.de>
 <00b501c6d6b4$632b7e90$9a02a8c0@pc>
 <10845a340609130053n395632f4ka5bbed3e49ce6ad2@mail.gmail.com>
 <0d4001c6d71a$fa124260$a900000a@adstate.local> <45081ABF.2020804@dealnews.com>
Subject: Re: [PHP-DEV] Return type hints
From: tslettebo@broadpark.no (=?UTF-8?Q?Terje_Sletteb=C3=B8?=)

> 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