Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72014
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.67 as permitted sender)
Message-ID: <52EEA7BE.4050500@sugarcrm.com>
Date: Sun, 02 Feb 2014 12:17:02 -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>
In-Reply-To: <52EE2B1D.7000307@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!

> 	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?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227