[PEPr] Changes in proposal for PHP::Assert

Peter Fiksman (http://pear.php.net/user/pfiksman) has edited the proposal for PHP::Assert. Change comment: Hello all, last year I proposed a new rather primitive package targeted to simplify writing assertions. The general idea is to use shortcuts like: Assert::thatTrue ($construction_to_check, $optional_msg); Assert::thatObj ($some_entity); (if an assertion fails, an exception is thrown.) and so on. The main argument against this package was "I better write a bit more code but reduce running times". a bit more code was meant to be, without explaining comments that could be needed: if ((5 == null) && ($doAssert)) { throw new SomeException(); } Now I have got the following points to discuss: ==== (1) === TEST SUITES ANS SPEED ======== I have written 2 small test suites, one to test my code and one to test the plain variant. proposed Assert: http://unips.sourceforge.net/pear/new_assert.phps conventional checks: http://unips.sourceforge.net/pear/assert_user_code.phps One test row is meant to be testing all assert variants one time each. This was looped 1,10,100,1000,10000 and 100000 times and the average time was calculated. The results are presented here: http://unips.sourceforge.net/pear/assertions_averages.jpg The results are quite interesting: 1) using the option to ignore the asserts is in both cases slower if disabled! so maybe this option cannot gain any perfomance. 2) my assertion method is as stated by many of you slower than the plain code - but not much. The tests show that both variants can be scaled without problems and my method is on this machine 0,08 millicesonds slower in average. Because one test row contains 13 assertions, one assertion produces approximately 6 microseconds slow-down! Consider a large-scale application having 300 000 lines of code. Because of the modularity one could hope there will be 100 000 LOC at most during one request that must be interpreted in the worst case. If there is an asserion every 10 lines of code, there are 10000 LOC with assertions. On my machine this would produce 0,06 seconds additional slow-down. compared to normal check I believe that is not that bad because my method allows structured assertions and better code readability. ==(2) NAMING ISSUES ============================ Its clear to me that the name PHP_Assert is not due to the PEAR code rules; nevertheless, the usage of string "PHP_Assert::thatTrue" implicates an action that should be done (compare to the original assert concept in Java) Maybe there are some other words those could be used being verb and substantive simlultaneously? I have no idea besides this one: "PHP_Check::thatTrue"... === (3) CONCLUDING WORDS SPEED vs. STRUCTURED PROGRAMMING ==== if we wanted to achieve the ultimative speed limits in the webapplications, we could use CGI programming with C instead of PHP... Structures like this Assert stuff produce more runtime inefficiency but I consider the better code to be more times valuable. I have finished a web portal with asserts and some other cool things I'll tell about later and on a 4-CPU server it is still okay. Test outputs: http://unips.sourceforge.net/pear/tests_new_assert.txt http://unips.sourceforge.net/pear/tests_old_assert.txt so long... Please review the proposal: http://pear.php.net/pepr/pepr-proposal-show.php?id=285 -- Sent by PEPr, the automatic proposal system at http://pear.php.net