Re: RFC: expectations/assertions

From: Date: Mon, 03 Feb 2014 21:58:33 +0000
Subject: Re: RFC: expectations/assertions
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-72136@lists.php.net to get a copy of this message
Hi!

> In main opinion, the main advantage of the proposal is ability to use of
> assert() function in production code with zero cost.
> It might be important, because cost of the assert() call and condition
> evaluation might be expensive.

I agree, this would be nice. Though it can be implemented using closures
and calling function only when needed. Granted, it is less convenient
and I'd like to have generic conditional compilation facility that could
help with it (or compiler/optimizer smart enough that if(<constant
false>) could be eliminated by it) but doing it as one-off hack for one
specific function doesn't look like ideal solution to me.

BTW, current patch has zend.assertions as INI_SYSTEM, which means the
whole server can either have assertions on or off. Which means if you
want to have two sites with different settings (like staging and
production, or production and debug copy), you'd have to set up separate
PHP server for each.

> It's similar to C which provides assert() function, but near every
> project defines ASSERT macro anyway, to eliminate assert() calls for
> release build.

In C, you can do it with NDEBUG setting, which works a bit differently -
you compile it once, and then it's predictable forever. With PHP it's
not that easy, unfortunately.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227


Thread (44 messages)

« previous php.internals (#72136) next »