Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83278
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fischer.name from 62.179.121.38 cause and error)
Message-ID: <54E6F48A.9040906@fischer.name>
Date: Fri, 20 Feb 2015 09:47:06 +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>	<54E5F77D.9090406@fischer.name> <CA+9eiLurXVtk0eKAuKF8uUb=6SVqZtatXSvZ9bnvW1gnb0hz4A@mail.gmail.com>
In-Reply-To: <CA+9eiLurXVtk0eKAuKF8uUb=6SVqZtatXSvZ9bnvW1gnb0hz4A@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:  On 19.02.15 16:23, Dmitry Stogov wrote: >> >> - 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 [...]
    
 
 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)


On 19.02.15 16:23, Dmitry Stogov wrote:
>>
>> - 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

Pardon me, but it doesn't explain what the role of the existing
"assert_options()" function will or does play?


>> - 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.

I don't understand this. "With 'foo' in production, you will be able to
switch to 'foo' at any time. With 'bar' of course not" ?

Maybe I was unclear. What I meant:
- a few paragraphs above it says that "-1 doesn't generate any code
(zero cost)"
- so why isn't THAT '-1' promoted to be the default in production
php.ini instead of '0' setting?


>> - 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.

Wow. The RFC doesn't explain this very well but I wrote this based on
assumption and guesswork.

This sounds two-folded to me: "very cool" (albeit I can't see a use-case
right now) on one hand and "utter magic" on the other.

With utter magic I mean: suddenly a function named 'assert' in a
namespace is eligible to rules before ever only applied to a global
existing function.

I'm not saying it's bad. It's just very magic, sounds cool but could be
a real PITA. Maybe just a documentation problem after all.



As Pierre already mentioned, the RFC really lacks some more details. But
in general, it looks good.

thank you,
- Markus