exectly :)
Thanks. Dmitry.
On Wed, Feb 5, 2014 at 10:21 AM, Nikita Popov <[email protected]> wrote:
> On Wed, Feb 5, 2014 at 4:11 AM, Yasuo Ohgaki <[email protected]> wrote:
>
> > Hi all,
> >
> > On Wed, Feb 5, 2014 at 7:53 AM, Yasuo Ohgaki <[email protected]> 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
>