Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58782
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: "Ferenc Kovacs" <tyra3l@gmail.com>, "Anthony Ferrara"
 <ircmaxell@gmail.com>
Cc: "Arvids Godjuks" <arvids.godjuks@gmail.com>, "Simon Schick"
 <simonsimcity@googlemail.com>, internals@lists.php.net
References: <CAJRMtAGqZCWThbZVztGN3-FyQ4MkJAs=uO_V-6pUCy9q2aAaZw@mail.gmail.com> <CAKOpQSyas7HSDXD5bftK9o18ucYAfQvxRtTUjYOgRSv_4nY-9A@mail.gmail.com> <CAJWj5+EQhhYDTh8DHwv2N4pk8FQybX3P5H292BGixbHSLB7k3A@mail.gmail.com> <CAAyV7nGQFrMoneDKvr0s1djOOkjn6rMj6PJcuB0842eA8EefOw@mail.gmail.com> <52.38.15021.3A1E65F4@pb1.pair.com> <4F570EBB.6030103@sugarcrm.com> <60744d7ea642fe03c7110502a3f4276a@mohiva.com> <CAAyV7nGZdq+TYU3eiQXj5CtEkRs84u_oOXRB7m+RNseU1QtG+Q@mail.gmail.com> <CAL0xaBHC8vFSnuezWwWqsBczHZA3uvgpb+K3z3z87Mc2Gbeseg@mail.gmail.com> <CAJWj5+HDyBvMGN7HiHBBEswr67s=tEfsTd3mHbzfeAZRrVmB2w@mail.gmail.com> <CAL0xaBGAHfOSR1g4meDsJfczBTR0dOfypBjHLXGT7h9o5T7eeA@mail.gmail.com> <CAH-PCH5SkZw2rSsqp5rYvfWtqCmQK6P+vU67zOgPiZ6sZ+Xedw@mail.gmail.com> <CAAyV7nHR5RzuZ2t7keyJ_Q_Hu__WED-12Z49Mpju2GXt=k5LEw@mail.gmail.com>
Date: Thu, 08 Mar 2012 13:58:22 +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_I=2ES=2ET=2E?=
Message-ID: <op.waurnkmoidpuyk@slws007.slhq.int>
In-Reply-To: <CAAyV7nHR5RzuZ2t7keyJ_Q_Hu__WED-12Z49Mpju2GXt=k5LEw@mail.gmail.com>
User-Agent: Opera Mail/11.61 (Win32)
Subject: Re: [PHP-DEV] Scalar Type Hinting
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

On Thu, 08 Mar 2012 13:38:32 +0100, Anthony Ferrara <ircmaxell@gmail.com>  
wrote:

>> AFAIR Gustavo, Anthony and Nikic discussed on IRC, that maybe the best
>> solution for scalar type hints would be the unification of the scalar  
>> type
>> hints with the current implementation of zend_parse_parameters.
>
> Yeah, that's basically what we were discussing.  However, there's one
> significant issue that I personally have to doing that.  in ZPP, if
> you have a parameter that expects an array, and pass it an int, a
> warning is raised.  But then the main body of the function is skipped
> (the function isn't executed) and the control is passed back to the
> calling code.

Not really, that's just a convention that if zpp fails functions return  
null or false immediately (which one is used depends on the extension,  
current weather, etc.). That's because there's a convention that builtin  
functions don't raise exceptions. But nothings stops them from falling  
back or suppressing the warning/notice (and some do, esp. if they support  
distinct sets of arguments).

Some extensions (and constructors even in extensions that use false for  
error) actually force an exception if zpp fails (usually via  
zend_replace_error_handling).

But of course this is not an option in user code because:
1) you can't change the error handling before parsing the parameters and
2) inside the function you can't tell whether some argument parsing error  
occurred.

So E_RECOVERABLE_ERROR in the cases where zpp would return FAILURE seems  
in fact the only viable option, even with the disadvantages it has  
(centralization and lack of flexibility).

Still, the fact that 100% consistency is not possible is not a strong  
argument against at least *some* consistency and in favor of inventing new  
rules.

> [...]

-- 
Gustavo Lopes