Re: Type hinting
| From: | Larry Garfield | Date: | Mon, 24 May 2010 05:45:47 +0000 |
| Subject: | Re: Type hinting | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-48417@lists.php.net to get a copy of this message | ||
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