Re: RFC: Expectations

On 10/21/2013 03:33 PM, Joe Watkins wrote:

On 10/21/2013 02:27 PM, Hochstrasser Christoph wrote:

Hi Derick,

This is again an RFC that does not even attempt to argue for its usefulness. "This functionality was meant to replace the assert() API that currently exists in PHP, because of problems replacing it in a compatible manner". This doesn't say what is wrong with assert() or whether we *need* expect.

The RFC was first proposed as a RFC to replace the "assert()" function with a "assert" keyword (which produces an opcode) in order to fix the unacceptable performance of the current "assert()" implementation. See also https://wiki.php.net/rfc/expectations#performance Later it was renamed to "expect" because the overall opinion was that changing "assert()" can't be done in 5.x. Yes, this RFC could state more clearly what its purpose is, but it certainly has usefulness. It's a lot faster than "assert()", when turned off "expect" becomes a NOOP, and it doesn't rely on "eval()".

Morning,

     I'm not so good at conveying ideas; the explanation you have there

is a summarized version of the java documentation of the same idea, the implementations are so similar they could be called identical.

     So everyone has a clear idea of how this works, here's some detail

about the op array for the statement "expect false;":

     Optimizations=On Expectations=On (DEVELOPMENT):

         opcodes[2]

             opcodes[0] -> ZEND_EXPCT expression
             opcodes[1] -> ZEND_RETURN

      Optimizations=Off Expectations=On:

         opcodes[9]

              opcodes[0]-opcodes[6] -> ZEND_NOP
              opcodes[7] -> ZEND_EXPCT expression
              opcodes[8] -> ZEND_RETURN

     Optimizations=On Expectations=Off (PRODUCTION)

         opcodes[1]

               opcodes[0] -> ZEND_RETURN

      Optimizations=Off Expectations=Off:

         opcodes[8]

                opcodes[0] -> ZEND_JMP opcodes[7]
                opcodes[1]-opcodes[6] -> ZEND_NOP
                opcodes[7] -> ZEND_RETURN

      The same opcodes for "assert("false")":

       Optimizations=Either Assertions=Either (LEGACY):

         opcodes[3]

                 opcodes[0] -> ZEND_SEND_VAL string
                 opcodes[1] -> ZEND_DO_FCALL assert
                 opcodes[2] -> ZEND_RETURN

        When Assertions=Off opcodes[1] does not result in a call to

eval, but the actual call to assert cannot be optimized, dragging down production considerably. Cheers Joe

When I wrote this it seemed wrong that there was padding ... and it was wrong, and it's since removed ... Below is corrected information which I shall include in the RFC. So everyone has a clear idea of how this works, here's some detail about the op array for the statement "expect false;":

      Optimizations=On Expectations=On (DEVELOPMENT):

          opcodes[2]

              opcodes[0] -> ZEND_EXPCT expression
              opcodes[1] -> ZEND_RETURN

       Optimizations=Off Expectations=On:

          opcodes[3]

               opcodes[0] -> ZEND_NOP
               opcodes[1] -> ZEND_EXPCT expression
               opcodes[2] -> ZEND_RETURN

      Optimizations=On Expectations=Off (PRODUCTION)

          opcodes[1]

                opcodes[0] -> ZEND_RETURN

       Optimizations=Off Expectations=Off:

          opcodes[2]

                 opcodes[0] -> ZEND_JMP opcodes[1]
                 opcodes[1] -> ZEND_RETURN

       The same opcodes for "assert("false")":

        Optimizations=Either Assertions=Either (LEGACY):

          opcodes[3]

                  opcodes[0] -> ZEND_SEND_VAL string
                  opcodes[1] -> ZEND_DO_FCALL assert
                  opcodes[2] -> ZEND_RETURN

         When Assertions=Off opcodes[1] does not result in a call to

eval, but the actual call to assert cannot be optimized, dragging down production considerably. Cheers Joe