Re: [PEPr] Comment on PHP::Assert

Joshua Eichorn wrote:

You might want to take this post by Travis about assert, he covers speed of assert and the overhead it gives. http://www.travisswicegood.com/index.php/2005/08/09/assert_good_or_evil I'm not really sure what your code provides that php's built in assert gives you besides being much much slower.

Josh beat me to the punch here. As I started to read through the commentary, I was thinking my article would be a good place to start as to whether this is a good idea or not. I did some testing of basic custom function asserts versus the internal assert(). There is no comparison between compiled and parsed code; parsed always looses. I wanted to give your code a quick look though, and I ran it through the benchmarking I used in my article. On a straight check to see if a value is an integer I got the following results: assert(is_int($i)) 1000000 times took 1.657171 Assert::thatInt($i) 1000000 times took 5.162074 If I start using single-quote assert()s, the time flips in favor of your code, but the single-quote assert gives me the ability to turn them off completely with assert_options(), your code doesn't take into account. Without the ability to shut them off, the asserts will always run, something that they don't really need to do. Any one of your that*() methods could easily be done by using the internal assert() and if Exceptions are the way you want to go, you can set it up to thrown an exception. This might be worthwhile as part of PECL to provide an extension to the basic assert() behavior, but without being compiled and without being aware of the ASSERT_ACTIVE constant, I would say this shouldn't be persued. As a side note, from the comments that have been posted, does no one realize that PHP has an assert() function? I know I don't see it much - ok, never - outside my own code, but you would think everybody knows that its there... Jesper Veggerby wrote while I was writing this reply:

... but since assert() drops a warning and returns true or false, I'd personally prefer the simple "if"-check and the exception, which you can at least catch in a try-catch (somewhere in the call-stack!) Not as assert() where you only can "catch" it at the assertion point (also with and if (and you have to use @assert()).

You can retool assert() to do whatever you like. See assert_options() for changing the callback. I've created a wrapper for throwing an AssertException. That said, assert() in general should always pass. By failing, it means your code would not be able to run as expected (i.e., an extension is missing, an improper argument has been passed in, etc.). -Travis