Re: RFC: expectations/assertions

From: Date: Tue, 04 Feb 2014 20:54:38 +0000
Subject: Re: RFC: expectations/assertions
References: 1  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message 
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]

Thread (44 messages)

« previous php.internals (#72209) next »