Re: RE: RFC: expectations/assertions

exectly :) Thanks. Dmitry. On Wed, Feb 5, 2014 at 10:21 AM, Nikita Popov <nikita.ppv@gmail.com> wrote: > 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 >