RE: [PHP-DEV] Follow-up to STH user experience, this time with actual testing
| From: | Zeev Suraski | 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