Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48428
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain geleia.net from 212.113.174.24 cause and error)
Message-ID: <42642.193.136.197.92.1274701739.squirrel@www.geleia.net>
In-Reply-To: <7.0.1.0.2.20100524075150.16056330@zend.com>
References: <7.0.1.0.2.20100522175819.0a601c68@zend.com>
    <AANLkTikpn-aj1A0VOnxUS-TMhb-xvDH6BmMEa_0nPsty@mail.gmail.com>
    <65101.93.108.152.52.1274662417.squirrel@www.geleia.net>
    <7.0.1.0.2.20100524075150.16056330@zend.com>
Date: Mon, 24 May 2010 12:48:59 +0100 (GMT Daylight Time)
To: "Zeev Suraski" <zeev@zend.com>
Cc: "Etienne Kneuss" <colder@php.net>,
 internals@lists.php.net
User-Agent: SquirrelMail/1.5.1
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Type hinting
From: spam@geleia.net

On Mon, May 24, 2010 6:09 am, Zeev Suraski wrote:
> At 03:53 24/05/2010, spam@geleia.net wrote:
>> On Sun, May 23, 2010 9:33 pm, Etienne Kneuss wrote:
>>> On Sat, May 22, 2010 at 17:04, Zeev Suraski <zeev@zend.com> wrote:
>>>
>>>> As one of the key people who designed PHP's type system I consider
>>>> strict type checks completely alien to and counterintuitive in PHP
>>>> and am therefore pushing to implement 'weak' typing instead, in a
>>>> way that's consistent and familiar to users.
>>
>> I agree. I added to the RFC a table with the current behavior of
>> current behavior of zend_parse_parameters (not sure if I should, feel
>> free to move it elsewhere). There are many differences between two. I
>> think the conversions should either be the same or it should be strict.
>>
>> Are users supposed to distinguish "string" as it appears in the
>> documentation from this new "string" in the functions' declaration?
>> Adding another inconsistency to PHP is not a very good idea, in my
>> opinion.
>
> 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.

I disagree. The === operator already checks the type of the variables.
Saying that the PHP programmers shouldn't have to worry about the type of
the variables  (that it's just an implementation detail) is pure fantasy.
Let's say I want to check whether some arbitrary user input is 0.

if (array_key_exists('quantity', $_POST) &&
    !is_array($_POST['quantity']) && $_POST['quantity'] == 0) { ... }

Now I have the condition evaluate to true if the user input was "abc". I'm
sure I come up with lots of examples where the type is important in PHP
and the programmer must be aware of it.

> 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.
>

That said, I don't think strict type checking is the best option. I just
think it's better than inventing a new complex set of rules that are
inconsistent with everything else. Otherwise, an "int" could mean that the
type is int (is_int), that zend_parse_parameters would accept it with the
flag "l" or "L",  or that it is an int in this new weak sense. Maybe we
could also add "is castable to an int" (which works with arrays, but not
with objects unless they implement get/cast). That would put us at 4
different meanings.

I think the best option is to align the type checking with
zend_parse_parameters (this is not the same as an implicit cast) and make
it stricter. This includes:
* disallow string to float/int when it contains non-numeric characters
(includes "123abc")
* disallow string/float to int when it causes overflow instead of the
current behavior (triple cast (long)(unsigned long)(long long)). "L" would
retain the current behavior.

Although a depart from backwards compatibility, I doubt this would cause
much brekage.

-- 
Gustavo Lopes