Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72209
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.177 as permitted sender)
Message-ID: <52F1538E.1080508@gmail.com>
Date: Tue, 04 Feb 2014 20:54:38 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <52EE2B1D.7000307@pthreads.org>
In-Reply-To: <52EE2B1D.7000307@pthreads.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: expectations/assertions
From: rowan.collins@gmail.com (Rowan Collins)

On 02/02/2014 11:25, Joe Watkins wrote:
> Morning Internals [, and Dmitry :)],
>
>     I came across a reason to think about assertions again today, my 
> original, pretty radical, patch was worked on by dmitry, I updated the 
> RFC a while ago but allowed the conversation to die down.
>
>     Nikita pointed this out around the same time:
>
>     https://gist.github.com/krakjoe/4a2145e5a6ddc26b1dc1
>
>     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.
>
>     So, I think now is a good time to revive the discussion, the patch 
> is pretty unobjectionable, and has been updated for master.
>
>     I'd like to move this to a vote pretty swiftly, any objections ?
>
> Cheers
> Joe
>

This is just a comment from someone without massively strong opinions on 
the proposal, but to me the RFC doesn't really make clear which parts of 
the proposed version of assert() are actually new. For instance, all the 
examples in the "Scope of Assertions" section are actually valid in 
current PHP, and if written to use eval()d strings could be used as the 
manual page for assert() today.

Without diving into the patch, I understand there to be two, somewhat 
independent, changes proposed here:

1) An ability to by-pass the asserted expression in the compiler but lay 
it out as plain PHP code, rather than an eval()'d string, combining the 
advantages of both versions currently supported. Some of your posts 
suggest that it is also more efficient even than the eval()d string 
version, but this isn't really clarified in the RFC. A new ini setting, 
zend.assert, is added to replace (or supplement?) assert.active to 
control this part of the behaviour.

2) A mode to throw Exceptions, rather than Warnings or just bailing, 
when an assertion fails. The first part of this is an extra assert 
option, assert.exceptions, which will cause the assertion to throw an 
AssertionException if it fails.

In addition, the second parameter ($message) is extended so that if an 
object descending from AssertException is passed, that will be thrown 
instead. Passing such an object in is probably only efficient in 
conjunction with the ability of the compiler to skip the entire 
expression, so somewhat relies on both of the above features.

Does this sound like a fair summary? If so, perhaps it could be added as 
an introduction in the RFC?

Regards,

-- 
Rowan Collins
[IMSoP]