Re: RFC: expectations/assertions

From: Date: Tue, 04 Feb 2014 05:36:27 +0000
Subject: Re: RFC: expectations/assertions
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
On Tue, Feb 4, 2014 at 1:58 AM, Stas Malyshev <[email protected]>wrote:

> 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)


Unfortunately, optimizer is not smart enough to solve this problem (on
purpose).
It may substitute only internal constants and constants defined in the same
file


> but doing it as one-off hack for one
> specific function doesn't look like ideal solution to me.
>

I wouldn't say it's an ideal solution. It's more a compromise that allows
safer checks in debugging and running in production without performance
lose. The solution also keeps full BC with old assert() behavior, that
wasn't trivial :)


>
> BTW, current patch has zend.assertions as INI_SYSTEM, which means the
> whole server can either have assertions on or off.


It's INI_SYSTEM on purpose. zend.assertions is a 3 way switch that may
disable code generation for assert().
Changing it after PHP files are already cached won't make any effect.


> 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.
>

yes.

>
>
> > 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.
>

So, C provides special handling for assert() as well :)

Thanks. Dmitry.


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


Thread (44 messages)

« previous php.internals (#72170) next »