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

Hi! > 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. That's why it is proposed to unify that and always produce E_CAST when implicit cast makes an "iffy" decision. As for the mode of failure where conversion can not be done - we can unify that too. The only reason why internals produced E_WARNING and not E_ERROR was because we did not have E_RECOVERABLE_ERROR but in general I see no problem with doing E_RECOVERABLE_ERROR every time cast can not be made, if it's done in PHP.next. Usually if you pass something unusable to the function, it's a sign of serious breakage, and function can not really continue. I don't see much problem with making it consistent E_RECOVERABLE_ERROR. > 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/ You say it as if it is an advantage. It is not. Having a rule that is subtly different in 10% of places is actually worse than having one totally different, because you start relying on it being the same, and you don't change your tests to capture the elusive 10%, and everything works just fine, and then you get in production scenario where data happens to hit that 10% and your code goes bananas. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/