Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72091
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 74.125.82.172 cause and error)
MIME-Version: 1.0
In-Reply-To: <52EF5588.6010902@sugarcrm.com>
References: <52EE2B1D.7000307@pthreads.org>
	<52EEA7BE.4050500@sugarcrm.com>
	<52EEF636.7010505@pthreads.org>
	<52EF5588.6010902@sugarcrm.com>
Date: Mon, 3 Feb 2014 21:29:05 +0400
Message-ID: <CA+9eiLvsF5Uu--TaZ9vDOn4iifK19Jdqi+iSrsxgZK8_Hx9Uug@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=001a11c34a6242dbcd04f183dc25
Subject: Re: [PHP-DEV] RFC: expectations/assertions
From: dmitry@zend.com (Dmitry Stogov)

--001a11c34a6242dbcd04f183dc25
Content-Type: text/plain; charset=UTF-8

Hi Stas,

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.

It's similar to C which provides assert() function, but near every project
defines ASSERT macro anyway, to eliminate assert() calls for release build.

Thanks. Dmitry.




On Mon, Feb 3, 2014 at 12:38 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > Well lets not forget that we already have an implementation as part of
> > the core, so to argue that we don't require assert in the core is moot;
> > we already have it.
>
> I'm not sure what you mean. We have assert function, a function among
> others. What you propose is special engine-level magic just for this
> function. The difference is like having a program that runs on Linux and
> does X and having special patch in Linux kernel just to do X. The bar
> for the latter is much higher.
>
> > While you can avoid some overhead in userland, you cannot remove the
> > overhead completely; a good assertion API should have no impact on
> > production, none, it should require no boilerplate code to make sane use
> > of it, at all, since it is meant to be a core feature.
>
> This is not completely fulfilled by your patch either - it still has an
> overhead of having the opcodes there and doing the jumps. If the code
> you're avoiding to run is heavy, then of course this overhead is
> negligible compared to the code you're avoiding, but the same then is
> true for purely userspace solution.
>
> > It would seem to create inconsistency, but only because it's compatible
> > with legacy code asserting strings, if you are smart, you will not
>
> It doesn't "seem" to create inconsistency. It creates it. It's not like
> I'm imagining two parameters doing the same thing :)
>
> > assert with strings and take advantage of the new implementation, if you
> > are not, you will continue to assert strings and be unaffected by the
> > new implementation ... that seems ideal to me, and Dmitry ...
>
> I don't think having a function that is half a function and half a magic
> engine constraint and that is controlled by two separate settings, one
> living in zend. and one in assert. is really ideal. Also, it is not true
> that string parameter is the only thing that controls it - as I already
> showed, how you call it also makes it work completely different and
> assert.* parameters still influence it even in magic mode, leading to
> such things as both throwing exceptions and bailing out - which I still
> don't understand how it's supposed to work.
>
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11c34a6242dbcd04f183dc25--