Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48430
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.185 as permitted sender)
Message-ID: <7.0.1.0.2.20100524150223.169b7b00@zend.com>
Date: Mon, 24 May 2010 15:12:41 +0300
To: spam@geleia.net
Cc: "Etienne Kneuss" <colder@php.net>,internals@lists.php.net
In-Reply-To: <42642.193.136.197.92.1274701739.squirrel@www.geleia.net>
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>
 <42642.193.136.197.92.1274701739.squirrel@www.geleia.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Type hinting
From: zeev@zend.com (Zeev Suraski)

At 14:48 24/05/2010, spam@geleia.net wrote:
>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.

We can agree to disagree regarding the level of understanding the 
average PHP developer has about zval.type - but it doesn't change my 
opinion that strict type checking would be the biggest inconsistency 
in PHP's core syntax ever.  These two assertions are independent from 
each other.

>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.

Suggest we put aside the 'is strict typing better than variant X of 
auto-conversion or not' discussion since it's mostly academic.  I 
think we both agree that we need to find the best version of auto-conversion.

>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.

Sounds acceptable to me, that's along the lines of the 3rd option 
which appears to be getting the most traction.  I'd also no 
conversion of arrays to scalars to that list.

Zeev