Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72170
Return-Path: <dmitry@zend.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 22127 invoked from network); 4 Feb 2014 05:36:32 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 4 Feb 2014 05:36:32 -0000
Authentication-Results: pb1.pair.com header.from=dmitry@zend.com; sender-id=unknown
Authentication-Results: pb1.pair.com smtp.mail=dmitry@zend.com; spf=permerror; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain zend.com from 74.125.82.180 cause and error)
X-PHP-List-Original-Sender: dmitry@zend.com
X-Host-Fingerprint: 74.125.82.180 mail-we0-f180.google.com  
Received: from [74.125.82.180] ([74.125.82.180:56667] helo=mail-we0-f180.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 2D/E1-09069-E5C70F25 for <internals@lists.php.net>; Tue, 04 Feb 2014 00:36:31 -0500
Received: by mail-we0-f180.google.com with SMTP id u57so3568532wes.39
        for <internals@lists.php.net>; Mon, 03 Feb 2014 21:36:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:date
         :message-id:subject:from:to:cc:content-type;
        bh=7rbHgrdk3PDGVS/Edzs8qB6mV1ndzNGTFEV73HF/qkk=;
        b=XjkOwMR/TszwS66/xRRt4oCGS5nY81bIVlmcRjUnCJ956Sni7rKieQqTT2f4u/JAWy
         /iV4iPboEkiQVH1RExSF57HeqUE2OL/+wC4jr2fbdlifffoB7ncmsqPi8AwUZfyjthj3
         U6vNt5nmfIdOu69sFd+m1T7Zc4pdgtKFSFIkeWXuoHcQwVdFbTRwZxeyyyv9laL7qcQT
         +wbplNtlEFGh1ww3vmyTokEL5jOFY9UkAMhRzJGpdxP/0tKfz6qkdfeFI72/LujBCScp
         kZTT2KKuH4AEsVfTbOQYubZroBIFHoW0qX69t2YOKn72H7x3P2GeI5UVroym92cqYbyY
         vDdQ==
X-Gm-Message-State: ALoCoQluiyGfs1kNE19a/zkodXgA09A7xgSysXNKgPpMKsUIC9bIKWK9EtVxBuRX8IjrAa5zh6WXTSQ0qfyaSvP+qaXtmnc+JuL1tJpNQQy81JYoZ0YfLel/VfxPj7KtFrrsiPbmn046
MIME-Version: 1.0
X-Received: by 10.180.91.17 with SMTP id ca17mr11293168wib.41.1391492187731;
 Mon, 03 Feb 2014 21:36:27 -0800 (PST)
Received: by 10.227.91.196 with HTTP; Mon, 3 Feb 2014 21:36:27 -0800 (PST)
In-Reply-To: <52F01109.3020705@sugarcrm.com>
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>
	<52F01109.3020705@sugarcrm.com>
Date: Tue, 4 Feb 2014 09:36:27 +0400
Message-ID: <CA+9eiLvrbWnmWjh3ovQbEpO9p5v=NwJf9GnDUie_wPE9MbpdoA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Joe Watkins <pthreads@pthreads.org>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043c7e828ed09904f18e0518
Subject: Re: [PHP-DEV] RFC: expectations/assertions
From: dmitry@zend.com (Dmitry Stogov)

--f46d043c7e828ed09904f18e0518
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 4, 2014 at 1:58 AM, Stas Malyshev <smalyshev@sugarcrm.com>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
>

--f46d043c7e828ed09904f18e0518--