Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69769
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.223.181 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <alpine.DEB.2.10.1310221001370.5542@whisky.home.derickrethans.nl>
References: <3D.BC.23638.84CA1625@pb1.pair.com> <alpine.DEB.2.10.1310211054300.5542@whisky.home.derickrethans.nl>
 <5264FE65.8050808@php.net> <alpine.DEB.2.10.1310221001370.5542@whisky.home.derickrethans.nl>
Date: Tue, 22 Oct 2013 10:20:38 -0700
Message-ID: <CADajX4BqUetQPPOefEetYFxVb0s4FNhAEvtXhgmCLCUouS19yg@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: Joe Watkins <krakjoe@php.net>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: Expectations
From: aharvey@php.net (Adam Harvey)

On 22 October 2013 02:08, Derick Rethans <derick@php.net> wrote:
> 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 =E2=80=94 this was a
long set of threads and I've been busy.