Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83193
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fischer.name from 62.179.121.48 cause and error)
Message-ID: <54E5F77D.9090406@fischer.name>
Date: Thu, 19 Feb 2015 15:47:25 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAL=_i_mdb1GvYFZr1ZEqvCgZ3+um-ZYuz5xAFZuwjwBcXsEk3Q@mail.gmail.com>
In-Reply-To: <CAL=_i_mdb1GvYFZr1ZEqvCgZ3+um-ZYuz5xAFZuwjwBcXsEk3Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Spam_score: -2.9
X-Spam_score_int: -28
X-Spam_bar: --
X-Spam_report: Spam detection software, running on the system "scanner01.home", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  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. [...] 
 
 Content analysis details:   (-2.9 points, 5.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                             [score: 0.0000]
Subject: Re: [PHP-DEV] [VOTE] Expectations
From: markus@fischer.name (Markus Fischer)

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.

- 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 ?

- 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?

- 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?

thank you,
- Markus