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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
