Re: [RFC] Scalar Type Hinting With Casts (re-opening)

From: Date: Wed, 16 Jul 2014 14:00:37 +0000
Subject: Re: [RFC] Scalar Type Hinting With Casts (re-opening)
References: 1 2 3 4 5 6 7 8 9 10 11  Groups: php.internals 
Request: Send a blank email to internals+get-75591@lists.php.net to get a copy of this message
On 16 Jul 2014, at 10:29, Zeev Suraski <zeev@zend.com> wrote: > For me the introduction of a new set of rules is a deal breaker. > I'm -1 on the RFC the way it is, and +1 if we implement these 'hints' as > implicit casts, plus change implicit casts to emit E_CAST in case of loss > of data or 'bogus' conversions. > > Why insist E_RECOVERABLE_ERROR and introduce this effectively new set of > rules, instead of switching to E_CAST and maintain consistency? > Maintaining consistency is a HUGE deal. Every such feature we add that > you need to learn more rules/exceptions for make PHP harder to learn. As has been pointed out already, that would be inconsistent with existing type hints. zend_parse_parameters emits E_WARNING and returns FAILURE, while type hints raise E_RECOVERABLE_ERROR. To make scalar type hints not emit E_RECOVERABLE_ERROR and instead do something weaker would introduce *more* inconsistency, not less. Also, again, while these new rules aren’t quite the same as zpp’s, they are largely the same, and these rules are able to be summed up clearly in a single sentence, unlike the confusing and inconsistent zpp rules. We could fix zpp later, but that would be harder as it would break backwards-compatibility. And again, these new rules only different from zpp in very few places (integral values, “123abc” and booleans). -- Andrea Faulds http://ajf.me/

« previous php.internals (#75591) next »