Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83204
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54E5F77D.9090406@fischer.name>
References: <CAL=_i_mdb1GvYFZr1ZEqvCgZ3+um-ZYuz5xAFZuwjwBcXsEk3Q@mail.gmail.com>
	<54E5F77D.9090406@fischer.name>
Date: Thu, 19 Feb 2015 19:23:53 +0400
Message-ID: <CA+9eiLurXVtk0eKAuKF8uUb=6SVqZtatXSvZ9bnvW1gnb0hz4A@mail.gmail.com>
To: Markus Fischer <markus@fischer.name>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b86d99012c927050f728604
Subject: Re: [PHP-DEV] [VOTE] Expectations
From: dmitry@zend.com (Dmitry Stogov)

--047d7b86d99012c927050f728604
Content-Type: text/plain; charset=UTF-8

On Thu, Feb 19, 2015 at 5:47 PM, Markus Fischer <markus@fischer.name> wrote:

> Hi,
>
> On 19.02.15 10:09, Joe Watkins wrote:
> > Morning internals,
> >
> >     The expectations RFC is now in voting phase:
> > https://wiki.php.net/rfc/expectations#vote
>
> - I somehow miss information what the exact differences are to the
> current implementation, to better judge the impact.
>

The implementation introduces ZEND_ASSERT_CHECK instruction that will jump
around calls to assert() depending on zend.assertions ini option. (call and
constraint evaluation may be expensive).

It's also possible to avoid compilation of asset() at all (setting
zend.assertions=-1)

This will allow using assert() for program testing, without performance
degradation in production.


>
> - how does zend.assertions and assert.exceptions work with
> "assert_options()" , i.e. isn't the exception behavior meant to be an
> addition to assert_options() too ?
>

zend.assertions control assert() compilation and execution

zend.assertions=-1 zero-cost, assert() won't be compiled at all (including
inner code)
zend.assertions=0  low-cost, assert() will be compiled but won't be
executes (including inner code)
zend.assertions=1  assert() wiil be compiled and executed as now


> - the RFC says: "enabled (zend.assertions=1) on development machines,
> and disabled (zend.assertions=0) in production"; a few paragraphs above
> it says "-1 - don't generate any code (zero-cost, production mode)".
> Shouldn't be -1 the default value for production then?
>

With zend.assertions=0 in production, you'll able to switch to
zend.assertions=0 at any time.
With zend.assertions=-1 of course not.


> - the RFC says: "A call to assert(), without a fully qualified namespace
> will call assert in the current namespace, if the function exists. An
> unqualified call to assert is subject to the same optimization
> configured by zend.assertions. ". Does this mean I can control whether a
> function in a namespace is being optimized-away with when zend.assertion
> equals -1 and otherwise do my own stuff in there and need to raise an
> AssertException on my own to signal assertion fails?
>

Yes. you are able to eliminate your own assert() functions in namespaces.

Thanks. Dmitry.


>
> thank you,
> - Markus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--047d7b86d99012c927050f728604--