Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69726
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: internals@lists.php.net,Derick Rethans <derick@php.net>
Message-ID: <5264FE65.8050808@php.net>
Date: Mon, 21 Oct 2013 11:13:57 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
References: <3D.BC.23638.84CA1625@pb1.pair.com> <alpine.DEB.2.10.1310211054300.5542@whisky.home.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.10.1310211054300.5542@whisky.home.derickrethans.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Expectations
From: krakjoe@php.net (Joe Watkins)

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.
>
> cheers,
> Derick
>

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.

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.
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.

Not all of the examples promote continuing execution, at all, I think 
only one actually does. I mention once that continuing execution is an 
option, just like it is when you catch any other exception.

Cheers
Joe