[VOTE] Expectations

Hi, On 19.02.15 10:09, Joe Watkins wrote:

- 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

On Thu, Feb 19, 2015 at 1:09 AM, Joe Watkins <pthreads@pthreads.org> wrote:

I totally miss the Expectation RFC announcement. Where the RFC was actually proposed for discussions. I have been following up the DbC thread, seeing some mentions but that's it. The RFC itself popped up 3 days ago. Also the RFC itself only point to various discussions, there is no summary, details, docs, examples, etc in the RFC. I am sorry but as much I like (for what I think it does) as I like the concept, this RFC does not have, by far, the quality I would expect for a RFC being voted on. Cheers,

Hey: On Thu, Feb 19, 2015 at 5:09 PM, Joe Watkins <pthreads@pthreads.org> wrote:

sorry, the thread is too long to read.. I am not sure whether there was some similar opinion before.. I voted without custom exception, that is because. if all assertion exception is AssertException, then we can simply optimized them away while zend.assert is disabled.. like: try { foo(); bar(); assert(); } catch (AssertException $e) { //these statements can be optimized away. } but with custom exception.. try { sqllitefunc(); // no threw sqllitefunc1(); //no threw assert("", new SqlLiteException()); } catch (SqlliteException $e) { //we are not sure maybe sqllitefunc can throw SqliteException. // thus we can not optimized these statements ayway } thanks

On 19 February 2015 at 01:09, Joe Watkins <pthreads@pthreads.org> wrote:

Sorry, I had an e-mail backlog while this was in discussion, so I'm only getting around to this now. Two thoughts: 1. This is awesome, particularly the BC aspects. Nice work. :) 2. For zend.assertions, is it worth defining constants with more meaningful names that can be used in place of the magic values? They're pretty arbitrary as it stands. My vote's not conditional on that — I'm +1 even in its current form — but I wonder if we can make this a little easier for users. Thanks, Adam

Le 19/02/2015 10:09, Joe Watkins a écrit :

Hi, While talking about this RFC with other people of AFUP, we discussed about assert()... And mostly ended up against "it". Still, note we probably discussed more about the idea of using assert() itself than about the RFC and the proposition of improving the existing assert() construct -- which means we probably didn't really answer the question that was asked here. Basically, the idea of adding code (assertions) directly into the code of our application in order to test for "things" doesn't feel right: we'd rather use (unit-)tests for that, alongside our application's code and not interleaved with it. Considering this, we kind of felt it wasn't really necessary to work on assertions and that enhancing them might encourage people to use them more -- adding more non-production code in the middle of the production-code. Also, using .ini directives to enable or disable the execution of portions of code comes with a risk: there is always a chance someone will mis-configure a server and assertions will run in production environment. Or maybe in some edge cases, an assertion could have some side-effect that would impact the code (even if it should not), making it work in development and not work in production? I hope I summarized our thoughts right -- and sorry if we didn't really answer the question that was asked. Thanks for your work!

On Thu, Feb 19, 2015 at 2:09 AM, Joe Watkins <pthreads@pthreads.org> wrote:

This announcement doesn't say when voting will close and the RFC doesn't either. When do you expect voting to close?