Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48416
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.20100524075150.16056330@zend.com>
Date: Mon, 24 May 2010 08:09:30 +0300
To: spam@geleia.net
Cc: "Etienne Kneuss" <colder@php.net>,internals@lists.php.net
In-Reply-To: <65101.93.108.152.52.1274662417.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>
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 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.
> >
> > -1, this table is very counter intuitive and is definitely not
> > consistent with the rest of PHP. Either make it strict or loose but not
> > halfway and in a bizarre way.
> >
>
>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.

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