Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48417
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 76.96.30.24 cause and error)
To: internals@lists.php.net
Date: Mon, 24 May 2010 00:45:47 -0500
User-Agent: KMail/1.12.2 (Linux/2.6.31-21-generic; KDE/4.3.2; x86_64; ; )
References: <7.0.1.0.2.20100522175819.0a601c68@zend.com> <65101.93.108.152.52.1274662417.squirrel@www.geleia.net> <7.0.1.0.2.20100524075150.16056330@zend.com>
In-Reply-To: <7.0.1.0.2.20100524075150.16056330@zend.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <201005240045.47532.larry@garfieldtech.com>
Subject: Re: [PHP-DEV] Type hinting
From: larry@garfieldtech.com (Larry Garfield)

On Monday 24 May 2010 12:09:30 am Zeev Suraski wrote:

> I have to say that I don't really see the logic in "either it should
> be identical to PHP's conversion rules or it should be 100.000%
> different (strict)".  Adding strict typing would be the largest
> inconsistency in PHP's core syntax, ever.
> 
> For that reason, I prefer pretty much any variation of the proposed
> solution over strict type checking.
> 
> I see three key options going forward:
> 1.  Implement the table along the lines of what it looks like now,
> perhaps with minor changes.
> 2.  Implement identical conversion rules to the ones that exist in
> PHP; That effectively turns type hinting into scalar casting
> operators (not saying that's a bad thing!)
> 3.  Implement identical conversion rules to the ones that exist in
> PHP, except for when they really suck.  Namely, lose the
> array->scalar conversions and silent conversions of non-numeric
> strings to numbers.
> 
> I personally lean towards #3.
> 
> Zeev

#3 is the one that seems like it would be most useful in practice, with one 
caveat.  If given an input of float(5.4) and a function parameter specified as 
int, there is data loss if you just do the equivalent of (int)$foo so that 
falls into the "really suck" category and should also explode.  (float(5), 
however, has no data loss in that operation so it's safe.)

I don't know if there's performance issues to address with that addition that 
may nix it, but that would be the ideal.

--Larry Garfield