Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72060
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.180 as permitted sender)
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 10:11:48 +0100
Message-ID: <CAEZPtU6=xDCe0SaTrVhqss3Q-H+dR6MLyy-7MZ2zBQTSkdgDtg@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Joe Watkins <pthreads@pthreads.org>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] RFC: expectations/assertions
From: pierre.php@gmail.com (Pierre Joye)

On Mon, Feb 3, 2014 at 9:38 AM, 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.

I fully agree here.

As the effort to reduce the impact of assert in production is much
appreciated I do not see much needs for this "addition".

I also discussed with a couple of developers being intensively
involved in testing tools and framework for php and the consensus is
that they do not need it for the large majority. A minority even
considers this feature as not really good, assert never was a good
thing to use (I never used for example).

Cheers,
--
Pierre

@pierrejoye | http://www.libgd.org