RE: [PHP-DEV] Follow-up to STH user experience, this time with actual testing

From: Date: Fri, 27 Feb 2015 09:48:22 +0000
Subject: RE: [PHP-DEV] Follow-up to STH user experience, this time with actual testing
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-83989@lists.php.net to get a copy of this message
> - PHPUnit passes a boolean false to debug_backtrace()... which > is > documented > as expecting an integer! (There are actually several constant values it > accepts, all of which are integer values.) In this case, PHPUnit is > relying > on the fact that the engine casts booleans to the integers 0 and 1. > (Zeev has > written to the list already indicating that this coercion path will be > supported in the patch.) Matthew, I just wanted to point out that actually, supporting boolean->int coercion is not planned. Converting boolean to integer is actually a very likely scenario where you'd have an outcome that you didn't expect. It's debatable whether sending false to a bitmask is OK or not, but given it's a bitmask, an explicit 0 is a lot more correct. > - PHPUnit is passing the results of $reflector->getDocComment() blindly to > substr() and preg_match*(). getDocComment() is documented as returning > EITHER > a string OR boolean false. Again, PHPUnit is relying on PHP to cast > boolean > false to an empty string. (Zeev has also indicated this coercion path > may be > re-introduced.) We're looking to re-introduce string->boolean (which will likely be common in database scenarios), but not the other way around - where it's very likely hiding a bug. Virtually all of the boolean->string coercions that were flagged as deprecated by the patch were at the very least suspects of being real world bugs. Thanks! Zeev

« previous php.internals (#83989) next »