Re: RE: RFC: expectations/assertions

On Wed, Feb 5, 2014 at 4:11 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > Hi all, > > On Wed, Feb 5, 2014 at 7:53 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > > > php > assert('function() {return FALSE;}'); > > php > assert('function() {return TRUE;}'); > > > > It does not work, but > > > > php > assert(eval('function() {return FALSE;};')); > > > > Warning: assert(): Assertion failed in php shell code on line 1 > > > > so closure in eval() works. I don't see reason not to allow closure > > directly. > > It only seems inconsistent to me. > > > > Added this to inconsistent behaviors RFC to track. > > https://wiki.php.net/rfc/inconsistent-behaviors#assert > There is a difference between f() and 'f'. The former is a function call, the latter a callback. The eval-behavior non-withstanding assert is essentially if (!$arg1) { error($arg2); }. So if (!f()) { ... } makes a lot of sense, but if (!function() {}) {} makes zero sense. Again, function() {} only creates a callback, but does *not* run it. To run it, you'd need something like (function(){})(). There is no inconsistency here. Allowing callables in general is not compatible with the existing string-eval mode and the expectation that arrays will assert true if they are non-empty. Adding only closures, *that* is inconsistent. Nikita