Req #49934 [Opn->Csd]: Add possibility to pass callbacks to assert()

Edit report at https://bugs.php.net/bug.php?id=49934&edit=1 ID: 49934 Updated by: tpunt@php.net Reported by: ninzya at inbox dot lv Summary: Add possibility to pass callbacks to assert() -Status: Open +Status: Closed Type: Feature/Change Request Package: *General Issues Operating System: * PHP Version: * -Assigned To: +Assigned To: tpunt Block user comment: N Private report: N New Comment: Zero cost assertions were introduced into PHP 7.0, so I'm closing this issue. Previous Comments: ------------------------------------------------------------------------ [2009-10-20 14:54:14] ninzya at inbox dot lv This is what i use right now in my apps: /** * Check if assertions are true (only in debug mode) * * @param callback.. $callbacks */ function assert_cb() { if( !DEBUG_MODE) // do not test for assertions in non-debug mode return; // we assume that all arguments are callbacks, so we // execute them one by one, until we get 'false' as a // result. foreach( func_get_args() as $cb) { if( call_user_func( $cb) ===false) { // assertion has failed throw new Exception( 'ASSERT_FAILED'); } } // all assertions are valid } ------------------------------------------------------------------------ [2009-10-20 14:38:32] ninzya at inbox dot lv Description: ------------ The current assert() implementation is very uncomfortable, for me at least. assert() does not skip code execution inside it's parentheses when assertions are disabled. Also, when you are using strings to optimize runtime of app having full of assert()s around in cases like this - assert( 'return false;') - is very hard to read, and, if variables are being also involved, the code looks very ugly and is error prone. I would like to propose to take the full advantage of closures and add possibility to pass callbacks to assert() function. Passing callbacks to this function would solve the both problems - bring in the readability, and would optimize runtime by not calling callbacks when assertions are disabled. The effect would be the same as if using strings as parameters, but the code would become more readable a look more nicer. Here is an example of how does assert() code look like in current PHP versions. Assume foo() is a method of an object: function foo( $bar) { // This way of testing assertion // results in a low performance, because when you disable // assertions, the code between parentheses is still being // executed, thus, resulting in a waste of computer resources. assert( !$bar->testAssert( '5')); // Another way of testing assertion. This is more optimized, // because the passed string is not eval()ed when assertion // checking is disabled. Good, but... strings? Unreadable, // ugly, error prone. Yes, i know, i could use double-quotes // here, but that's not the point, strings are no way to good, // maintainable code. assert( '!$bar->testAssert( \'5\')'); } Here is an example of what i would like to see in PHP: function foo( $bar) { // The new way of testing assertion. Code is good, IDEs can take // advantage of a PHP syntax and highlight the statements for me // in my closure. Readable, sexy, way better, than having strings. // Also, closures allow to encapsulate larger blocks of code, which // with string approach would result in a multi-line string // concatenation hell. assert( function(){ return $bar->testAssert( 5); }); // As closures are callbacks by their type, the string callback also // should be valid as assert()'s param: assert( 'MyClass::myTestAssertion'); } And here comes the problem, right, how to distinguish between strings of code ('!$bar->testAssert( \'5\')') and strings - callbacks ('MyClass::myTestAssertion')? Right, there's no good way to do this, so i propose to create a separate version of assert(), for example, assert_cb() (assert by callback), to maintain compatibility with those, who use the old assertion testing approach. Reproduce code: --------------- - Expected result: ---------------- - Actual result: -------------- - ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=49934&edit=1