On 10/22/2013 10:08 AM, Derick Rethans wrote:
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
Morning Derick,
I have not changed what an exception is,
that an ExpectationException does change what Zend does,
that it will not intrude on the expected behaviour of any aspect in any case
The reasons C should immediately abort do not stand here, when an assertion fails in C it can do useful things; generate a core dump and quit. We cannot do that, we must allow the programmer to collect state and other information to help them avoid the same exception again. All of the modern implementations of assertion do exactly the same thing, even our old implementation takes a callback (requiring module globals and all that junk) for what I can only imagine are the same reasons.
So with the fact established that errors should be manageable, and is it a fact; we can do one of two things, we can accept a callback, which requires module globals, ini settings, userland functions .. or it we can support it where the feature actually is, at the level of Zend, in the language.
It seems elegant and obvious to allow failed assertions to throw exceptions and for them to be managed as any other exception in PHP, or not - which DOES result in abortion, lets not forget that fact. I'm not sure the examples show this, but the majority of them are copied verbatim from the Java documentation of the same feature, we appear to disagree on the ones I thought I would drop in.
Perhaps my mistake, I don't know ... to be clear: This is implemented as it is in Java and a few other modern implementations besides, I am not changing what assertions are, where they should and shouldn't be used and what for, it is _exactly_ the same as Java, intended to be used just as it is in Java, another high level programming language. Ruby is the same, and three independent implementations for various Javascript engines, all high level implementations ...
So certainly, I'm not alone in my assertion; we should definitely use exceptions.
About the lacking info in the RFC, the information you seek to have included is actually there, the original thread is referenced, I'm not sure it is necessary to reproduce the essence of the conversation in the RFC, by the time it was written certain facts seemed all but established, so I thought I would start from where we were then, rather than from the beginning of the original thread.
It's all very well to say lets not take implementation or change too lightly, but then, we do have an absolutely terrible implementation of assertion, that pernicious decision was allowed to pass without anyone pointing out that certain things are absolutely required from an implementation of assertion for it to be considered useful, it was short sighted and unnecessary to include an implementation of something that requires support by the engine for it to be usable the way it is intended to be used.
I'm not taking anything lightly, I'm solving an actual problem here, not introducing something new, but properly supporting something we are documented to support.
Cheers
Joe