Re: Scalar Type Hinting

From: Date: Thu, 08 Mar 2012 12:58:22 +0000
Subject: Re: Scalar Type Hinting
References: 1 2 3 4 5 6 7 8 9 10 11 12 13  Groups: php.internals 
Request: Send a blank email to internals+get-58782@lists.php.net to get a copy of this message
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

« previous php.internals (#58782) next »