Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72136
Return-Path: <smalyshev@sugarcrm.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 59404 invoked from network); 3 Feb 2014 21:58:31 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 3 Feb 2014 21:58:31 -0000
Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.99 as permitted sender)
X-PHP-List-Original-Sender: smalyshev@sugarcrm.com
X-Host-Fingerprint: 108.166.43.99 smtp99.ord1c.emailsrvr.com Linux 2.6
Received: from [108.166.43.99] ([108.166.43.99:43941] helo=smtp99.ord1c.emailsrvr.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 26/48-35654-60110F25 for <internals@lists.php.net>; Mon, 03 Feb 2014 16:58:30 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by smtp5.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 500591B01E0;
	Mon,  3 Feb 2014 16:58:27 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp5.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id F09871B01A9;
	Mon,  3 Feb 2014 16:58:26 -0500 (EST)
Message-ID: <52F01109.3020705@sugarcrm.com>
Date: Mon, 03 Feb 2014 13:58:33 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Dmitry Stogov <dmitry@zend.com>
CC: Joe Watkins <pthreads@pthreads.org>, 
 PHP internals <internals@lists.php.net>
References: <52EE2B1D.7000307@pthreads.org>	<52EEA7BE.4050500@sugarcrm.com>	<52EEF636.7010505@pthreads.org>	<52EF5588.6010902@sugarcrm.com> <CA+9eiLvsF5Uu--TaZ9vDOn4iifK19Jdqi+iSrsxgZK8_Hx9Uug@mail.gmail.com>
In-Reply-To: <CA+9eiLvsF5Uu--TaZ9vDOn4iifK19Jdqi+iSrsxgZK8_Hx9Uug@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: expectations/assertions
From: smalyshev@sugarcrm.com (Stas Malyshev)

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