On 15 Jul 2014, at 22:02, Stas Malyshev <[email protected]> wrote:
> That's exactly what I want to avoid - having several forms of casts with
> different rules. One is good, two is kind of OK, three is too much.
> Especially as you won't even know which rules something as simple as
> foo($bar) would invoke.
To be fair, we already have this. The type hint convention is
E_RECOVERABLE_ERROR, the zend_parse_parameters convention is E_WARNING and
return FAILURE (usually resulting in a bailout and hence NULL result in the
function calling zpp).
I’d rather make type hints do the right thing here now and hopefully change zpp
later, whether that’s realistically achievable or not. Unfortunately we already
have two different error behaviours, and I expect resistance to changing type
hints to do what zpp does ("too soft touch!"), or changing zpp to do what type
hints do ("too harsh!”).
Also, sure, the scalar type hint behaviour is inconsistent with zpp in some
cases (booleans, 12.5, “12a”), but it’s inconsistent with most of it, and you
can describe what they do with a single sentence (“Scalar type hints will raise
E_RECOVERABLE_ERROR if information is lost when casting.”), since they’re far
more straightforward and obvious than zpp’s rules are.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
