Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69772
Return-Path: <pthreads@pthreads.org>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 46989 invoked from network); 22 Oct 2013 17:32:36 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 22 Oct 2013 17:32:36 -0000
Authentication-Results: pb1.pair.com header.from=pthreads@pthreads.org; sender-id=unknown
Authentication-Results: pb1.pair.com smtp.mail=pthreads@pthreads.org; spf=permerror; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.212.171 cause and error)
X-PHP-List-Original-Sender: pthreads@pthreads.org
X-Host-Fingerprint: 209.85.212.171 mail-wi0-f171.google.com  
Received: from [209.85.212.171] ([209.85.212.171:38913] helo=mail-wi0-f171.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id C1/A8-10840-3B6B6625 for <internals@lists.php.net>; Tue, 22 Oct 2013 13:32:36 -0400
Received: by mail-wi0-f171.google.com with SMTP id h11so6087464wiv.4
        for <internals@lists.php.net>; Tue, 22 Oct 2013 10:32:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
         :subject:references:in-reply-to:content-type
         :content-transfer-encoding;
        bh=SqIRn+fy0G8TKCanLBvoP4fJJds5esvA/EDO/bYNpO8=;
        b=Xh5/G+BrvPSouUW/6pvTAxEg+x3mFF6sq5ltExFDtK2Gi03yE8M/7uD0NouOwyVbQV
         kodc1P5GO63z0zzxMnB4977hKZwO8ejnyqvbGzk1EkMgNBER5rJAek+M25LraGtP07aS
         AduZ1onKl4o/sVp+dIeZY9GY95P9Hyz2leL87J0bt5X9C7/DH1xOchGyFfF3V/tk0DgH
         UowARaaBeOl7NroZXjOpBHx8VWyLixN423gnlhZslVzvAElwiQpmUgwNrdebyIzoMHd9
         0Ty4ewpMx8uK1fr1y2vXMjcrOx1OE7MOKVrbRfhvb3oMnnXBF8aQwdYWJWqW2/hszoN4
         7Agg==
X-Gm-Message-State: ALoCoQmCIcrYCsHHCRhQQ4G9/24pav39qHr0y9gdoYYjscCTmUNm66GWN09TgkDZqVU3DsQNABMl
X-Received: by 10.180.37.162 with SMTP id z2mr15362708wij.58.1382463152523;
        Tue, 22 Oct 2013 10:32:32 -0700 (PDT)
Received: from [192.168.0.3] (cpc22-asfd3-2-0-cust209.1-2.cable.virginm.net. [80.4.21.210])
        by mx.google.com with ESMTPSA id ey4sm8552560wic.11.2013.10.22.10.32.28
        for <multiple recipients>
        (version=TLSv1 cipher=RC4-SHA bits=128/128);
        Tue, 22 Oct 2013 10:32:31 -0700 (PDT)
Message-ID: <5266B6A8.4010607@pthreads.org>
Date: Tue, 22 Oct 2013 18:32:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Adam Harvey <aharvey@php.net>, internals@lists.php.net
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>
In-Reply-To: <CADajX4BqUetQPPOefEetYFxVb0s4FNhAEvtXhgmCLCUouS19yg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] RFC: Expectations
From: pthreads@pthreads.org (Joe Watkins)

On 10/22/2013 06:20 PM, Adam Harvey wrote:
> 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 — this was a
> long set of threads and I've been busy.
I'm a bit perplexed at the need to retain any compatibility with what is 
a poor implementation ?

I've mentioned that retaining compatibility is a restriction on this 
implementation, I guess assuming the reasons were obvious. I've brushed 
over them, but to be explicit, backwards compatible means multiple ini 
settings, at least one userland function, module globals, and confusion. 
It means being able to disable and enable assertions at _runtime_, 
impacting the implementation and every op array that uses it in 
_production environments_. All these things make the implementation less 
suitable as an implementation of assertion and I do not see a need to 
restrict it in this way.

Cheers
Joe