Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69773
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.223.169 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <5266B6A8.4010607@pthreads.org>
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>
 <CADajX4BqUetQPPOefEetYFxVb0s4FNhAEvtXhgmCLCUouS19yg@mail.gmail.com> <5266B6A8.4010607@pthreads.org>
Date: Tue, 22 Oct 2013 10:56:58 -0700
Message-ID: <CADajX4CDvrHc8PoiOyfCM8601AcZjEM6Cw_X0+O=hJSPT65d_A@mail.gmail.com>
To: Joe Watkins <pthreads@pthreads.org>
Cc: PHP internals <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 10:32, Joe Watkins <pthreads@pthreads.org> wrote:
> On 10/22/2013 06:20 PM, Adam Harvey wrote:
>> 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.
>
> I'm a bit perplexed at the need to retain any compatibility with what is =
a
> poor implementation ?

To be fair, I think part of the disconnect here is that I don't feel
like the current implementation is particularly poor besides the
eval-based API. I don't really want an assertion failure to throw an
exception =E2=80=94 if I did, I'd use an assert callback or ErrorException =
to
do that. I want it logged so I can look at it later, and that's easily
configured with the current assertion setup.

I guess I'm wondering if there's a middle ground here, rather than
throwing the assertion baby out with the bathwater in favour of an
entirely new thing that could simply be syntax sugar sprinkled over an
existing, working implementation.

Adam