Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49353
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.22 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: internals@lists.php.net
References: <AANLkTim7sNwZWyo8dQz-o6S=Tta-OGYqnDM0cDJX3A49@mail.gmail.com>
 <1281478269.6608.292.camel@guybrush>
 <alpine.DEB.2.00.1008102325440.29410@kossu.derickrethans.nl>
 <4C61D6D0.90907@sugarcrm.com>
 <AANLkTinATNjUXa1WUNBpFu0tL8LTd091H1jRPP9iiRSv@mail.gmail.com>
 <4C62B9E0.4030305@gmail.com>
 <AANLkTin=AS5iR5vXVjfDA_fitnua8+9D9rrpKtBZvWc9@mail.gmail.com>
Date: Wed, 11 Aug 2010 17:29:21 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_IST?=
Message-ID: <op.vg9727zyidpuyk@damnation.dulce.lo.geleia.net>
In-Reply-To: <AANLkTin=AS5iR5vXVjfDA_fitnua8+9D9rrpKtBZvWc9@mail.gmail.com>
User-Agent: Opera Mail/10.60 (Win32)
Subject: Re: [PHP-DEV] Strict typing
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Wed, 11 Aug 2010 16:03:14 +0100, Alexey Zakhlestin <indeyets@gmail.com>  
wrote:

> 2010/8/11 Ryan Panning <rpanning@gmail.com>:
>
>> Because the current syntax used for type hinting
>> classes/arrays is strict. If changed, you would need to specify that  
>> scaler
>> types are weak but classnames are strict and now you have a WTH moment.
>
> Not really. Class type-hinting is not strict. The only reason why it
> looks strict is, that PHP doesn't provide userland ways for
> object-casting.
> As far as I remember, zend-engine, underneath, actually has hook for
> casting. And nothing stops us from supporting such casting with hints,
> eventually.
>

If you're referring to the cast_object handler, the only thing it can  
specify in terms of the target type  is IS_STRING, IS_OBJECT, etc.

I don't think what we have now and both strategies that are being  
considered are directly comparable, so the "the current type hinting*  
is/is not strict" and "the new strategy is/is not consistent with current  
type hinting" are just rhetoric.

I'm my opinion, what we should strive for is consistency with the only  
comparable thing, the current parsing API, zend_parse_parameters. If an  
internal function says it accepts an array, it can only take an array**.  
If it says it only accepts an object of a certain type, it checks the  
inheritance hierarchy***. So the current type hinting implementation is  
already consistent with zend_parse_parameters.

Unfortunately, both competing options want to deviate from this:
- The strict side wants a simple, 'gettype' like check, that has nothing  
to do with the current API.
- The weak side thinks the current parameter parsing API is a bit loose  
(for instance, if I'm not mistaken, all the scalars are automatically  
converted to bool), so it's better to create a whole new set of rules,  
even though they will still deviate slightly from the current API.

In my opinion, the transition should be made slowly. First, by raising a  
warning on the undesirable automatic conversions we don't want, and  
finally disallowing them altogether and introducing a compatible  
user-space type hinting.

* terminology objections aside
** the rare 'H'/'A', which also take an object, excluded)
*** 'o' can also be given, which accepts all the object types

-- 
Gustavo Lopes