Re: [RFC] Scalar Type Hinting With Casts (re-opening)
| From: | Andrea Faulds | 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/