Re: RFC: Expectations

On Mon, 21 Oct 2013, Joe Watkins wrote: > On 10/21/2013 10:57 AM, Derick Rethans wrote: > > On Fri, 18 Oct 2013, Joe Watkins wrote: > > > > > Evening Chaps, > > > > > > Following on from discussion regarding assertion API in PHP, the > > > following RFC is now up for discussion: > > > > > > https://wiki.php.net/rfc/expectations > > > > > > Please do point out any missing sections or information, so that it > > > can be clarified as quickly as possible. > > > > > > I hope this conveys the idea a bit clearer to everyone ? > > > > This is again an RFC that does not even attempt to argue for its > > usefulness. "This functionality was meant to replace the assert() API > > that currently exists in PHP, because of problems replacing it in a > > compatible manner". This doesn't say what is wrong with assert() or > > whether we *need* expect. > > > > Besides that, why support execptions here. asserts are for testing > > things in development in order not to cock things up. Using exceptions > > for this makes very little sense. All of your examples even promote to > > handle exceptions and continue with excecution. If you want that, just > > use normal if()s with exceptions. I don't see the point of yet another > > syntax extension to do things you can already do just fine. > > The performance of the current assert API is unacceptable during > development due to the fact it is a function that utilizes strings and > eval, and cannot be disabled completely during production because it's > a function not a language construct. This makes it quite devastating > to deploy, it seems obvious we should seek to replace it. I wasn't arguing about its merits, only that the RFC should contain the whole story of *why* we want to change the language. IMO RFCs often only including weak reasons and there needs to be a really strong case (not like "I don't like how it works" or "I'd like this to thrown exceptions") for changing the *language*. Don't take changing the language and/or syntax to lightly. > We should support exceptions here because it gives a reasonable way to manage > the error without impacting anything else, without requiring module globals, > ini settings, or supporting functions in userland. Not part of my original email, but I disagree here. An assertion/expectation is a last moment resort which should abort an application as to prevent harm being done, just like the C library's "assert": ASSERT(3) Linux Programmer's Manual ASSERT(3) NAME assert - abort the program if assertion is false > By manage I do not necessarily mean continue executing, I mean that it > is never really acceptable or useful for a web application to quit, > writing a single exception to standard error. It is useful to be able > to manage the error to collect more information about the state of the > application, gain access to a stack trace, and do something actually > useful. You're contradicting yourself here. You say that you don't necessarily want to continue executing, but that's exactly what handling exception handling does. You're now changing "assertions" to something that has parts that are always available (the exception handling) and things that are compiled out (the "expectations") - which doesn't make a lot of sense to me. You don't need "expectations" for this as you can already do this just fine (by throwing exceptions). I'm pretty convinced that expectations *without* exceptions are a good idea, as using assert (which is really eval) is a nasty thing that should be replaced, but IMO exception throwing should not be part of this feature. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine