Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72058
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.115 as permitted sender)
Message-ID: <52EF5588.6010902@sugarcrm.com>
Date: Mon, 03 Feb 2014 00:38:32 -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: Joe Watkins <pthreads@pthreads.org>, 
 PHP internals <internals@lists.php.net>
References: <52EE2B1D.7000307@pthreads.org> <52EEA7BE.4050500@sugarcrm.com> <52EEF636.7010505@pthreads.org>
In-Reply-To: <52EEF636.7010505@pthreads.org>
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!

> 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