Re: RE: RFC: expectations/assertions

Hi Stas, On Wed, Feb 5, 2014 at 4:58 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote: > > This form > > > > assert(function func() { > > // some code here > > }); > > You probably meant to write a closure (anonymous function) there. So you > Yes. > actually want assert to support calling closures. This would be a BC > break, but it is very easy to make your own assert that does just that. > If we allow any callable, it's would be BC break since callable could be string (function name). > > > I'm sure most users are used to latter form, since this form > > is used extensively in JavaScript. It keeps variable scope > > clean, too. > > No users of PHP are used to this form since this form does not exist in > PHP. As for Javascript users, there's no assert in standards, but many > browsers support console.assert - which works exactly like PHP assert > (without eval stuff) and does not support calling closures either. > See e.g. http://stackoverflow.com/q/15313418/214196 > So I wonder how Javascript users would get used to that I meant the form of the code, not assert(). JavaScript uses callbacks extensively and users are used to it. PHP users are also getting used to it since the introduction of closure. If we are going to support closure only callback, then everything is ok for assert() to call closure, I suppose. Sorry that I wrote the same thing 3 times in this thread, but assert(function() { // some code }); would keep variable scope/name space clean when user would like to use call back. $f = function f() {}; assert($f()); OR function f() {} assert(f()); I think it's nice to have clean variable scope/name space with assert(). Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net