Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72031
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 74.125.82.172 cause and error)
Message-ID: <52EEF636.7010505@pthreads.org>
Date: Mon, 03 Feb 2014 01:51:50 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>, 
 PHP internals <internals@lists.php.net>
References: <52EE2B1D.7000307@pthreads.org> <52EEA7BE.4050500@sugarcrm.com>
In-Reply-To: <52EEA7BE.4050500@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: expectations/assertions
From: pthreads@pthreads.org (Joe Watkins)

On 02/02/2014 08:17 PM, Stas Malyshev wrote:
> Hi!
>
>> 	Still, there's no reason for us to have a crappy assertion api as part
>> of the core just because there's a way around it(-ish) in user land.
> I think there is some reason - if it can easily be done in userland,
> with more flexibility and suitability for particular purposes of the
> user, why put it in core? If it's such a common feature, make a PSR for
> it and create reference implementation that everybody would be using. So
> my question is - what having in core adds to it that can't be done as
> easily in userland?
>
> Also, it essentially splits assert() into two completely independent
> things one of them being regular function that you can call and another
> being weird magic thing. Moreover, for the same assert there's now two
> completely independent ways of controlling it - one is zend.assert and
> another is assert_options/ASSERT_ACTIVE. E.g. compare:
>
> // This is controlled by zend.assert
> assert($foo > 1, "Foo is too small");
>
> // This is controlled by assert_options
> $f = 'assert';
> $f($foo > 1, "Foo is too small");
>
> This looks a bit strange for me.
>
> Also, assert() will throw exception if assert.bail = 1 and
> assert.exception = 1, but only if the argument is not a string. If the
> argument is a string no exception will be thrown. OTOH, if the argument
> IS a string, assert will both throw exception *and* bail out, which is
> not clear what is the purpose of that.
>
> I'm also feeling a bit uneasy with adding more and more special cases
> for special names in the engine. Maybe we could create some more generic
> facility that would not need to be one-off case for just one function?

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.

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.

It would seem to create inconsistency, but only because it's compatible 
with legacy code asserting strings, if you are smart, you will not 
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 ...

Cheers
Joe