Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69744
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Tue, 22 Oct 2013 10:08:58 +0100 (BST)
To: Joe Watkins <krakjoe@php.net>
cc: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <5264FE65.8050808@php.net>
Message-ID: <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>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] RFC: Expectations
From: derick@php.net (Derick Rethans)

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

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine