RFC: Expectations View as Markdown

It does say zend.expectations=1 in the config section, I'm not able to
say what production/dev default settings will be.

I would assume that you'd want to state in the RFC that it would be
default '1' in development, and default '0' in production. Based upon
the so far discussed use cases.

Eli

Have updated the note with clarity ...

Cheers
Joe

So looks like we need a new name ?? Ideas ??

Hmm... posit, assume, demand, presume. I rather like demand; it has that air of be-true-or-else that fits the occasion.

--
Bob Williams

Notice: This communication, including attachments, may contain information that is confidential. It constitutes non-public information intended to be conveyed only to the designated recipient(s). If the reader or recipient of this communication is not the intended recipient, an employee or agent of the intended recipient who is responsible for delivering it to the intended recipient, or if you believe that you have received this communication in error, please notify the sender immediately by return e-mail and promptly delete this e-mail, including attachments without reading or saving them in any manner. The unauthorized use, dissemination, distribution, or reproduction of this e-mail, including attachments, is prohibited and may be unlawful. If you have received this email in error, please notify us immediately by e-mail or telephone and delete the e-mail and the attachments (if any).

Since this would throw exceptions, could it look like (or be) a
final/abstract (although PHP doesn't allow that combo for some reason)
class with static methods?

Assert::isTrue($expr, $msg);

That syntax is already valid (so of course there are BC issues) and I
don't know how practical it is to optimize that away to nothing, but
it would be more consistent with regard to throwing exceptions and
would allow for a variety of different class methods.

--
Matthew Leverton

Heya,

I do not know how much it concerns this RFC but I came across the
following
page about an extension named "Expect" when I was searching for RFC
Expect
with google.
http://php.net/manual/en/book.expect.php

I suppose there would be a name clash between the extension and the new
expect keyword. I do not know how internals usually deal with such
problems,
especially if it is within an extension, but I am sure someone will know
it.

Cheers,
Robert

it was discussed on irc, there is not problem here, because the ext name
and the function name can't clash, and the ext doesn't have a function
with
the name of expect, so everything is fine afaik.

Rasmus has pointed out that there is an expect:// stream wrapper.

So looks like we need a new name ?? Ideas ??

Cheers
Joe

Heya,

I do not know how much it concerns this RFC but I came across the
following
page about an extension named "Expect" when I was searching for RFC
Expect
with google.
http://php.net/manual/en/book.**expect.phphttp://php.net/manual/en/book.expect.php

I suppose there would be a name clash between the extension and the new
expect keyword. I do not know how internals usually deal with such
problems,
especially if it is within an extension, but I am sure someone will know
it.

Cheers,
Robert

it was discussed on irc, there is not problem here, because the ext name
and the function name can't clash, and the ext doesn't have a function
with
the name of expect, so everything is fine afaik.

Rasmus has pointed out that there is an expect:// stream wrapper.

So looks like we need a new name ?? Ideas ??

Why ?

The stream wrapper is always used in a string, so there is no parsing
problem about the "expect" keyword.
Am I missing something ?

Julien.Pauli

Am 21.10.2013 03:52 schrieb "Joe Watkins" krakjoe@php.net:

So looks like we need a new name ?? Ideas ??

abstract EXPRESSION

abstract is already a keyword, so no BC.

abstract is not concrete so alludes a bit to the
might-be-or-might-not-be-checked nature of the test

abstract is the name for the "short summary" intro part of scientific
papers, and these conditions are kind of a summary of what is known
(preconditions) and concluded (postconditions).

best regards
Patrick

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'd like to say that, I thought this must be the case, there is no way
Derick is asking me to justify assertion ... @internals can be a bit
heated, I dunno why, we are all reasonable chaps :)

I think C is the wrong direction to look for inspiration here, there are
plenty of implementations of assertion that do throw exceptions, I've
linked to them in the RFC yesterday. The reasons should be palatable; an
exception provides a stack trace, it allows the failure to be graceful.

It does not promote continuing execution, and if you look with a cool
head on you can see I done that once, only to show that:
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

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.

I agree that something to replace the eval-based assert() would be
good. What if the new syntax simply respected assert_options(), and
assert_options() was extended to support an explicit ASSERT_EXCEPTION
control option (that presumably took an exception class name as its
option value)? That seems like it would provide the exception based
possibilities that some posters want while maintaining the same
assertion behaviour that users are already used to by default.

Adam, who apologises if this has been suggested before — this was a
long set of threads and I've been busy.