Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69733
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 74.125.82.50 cause and error)
Message-ID: <52653B30.8050906@pthreads.org>
Date: Mon, 21 Oct 2013 15:33:20 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Hochstrasser Christoph <christophhhochstrasser@fastmail.fm>, 
 internals@lists.php.net
References: <3D.BC.23638.84CA1625@pb1.pair.com> <alpine.DEB.2.10.1310211054300.5542@whisky.home.derickrethans.nl> <5A140DF2-A29B-4804-A65C-37F6FB28D383@fastmail.fm>
In-Reply-To: <5A140DF2-A29B-4804-A65C-37F6FB28D383@fastmail.fm>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Expectations
From: pthreads@pthreads.org (Joe Watkins)

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