Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83912 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 49539 invoked from network); 26 Feb 2015 18:15:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Feb 2015 18:15:00 -0000 Authentication-Results: pb1.pair.com smtp.mail=mailing@pascal-martin.fr; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=mailing@pascal-martin.fr; sender-id=pass Received-SPF: pass (pb1.pair.com: domain pascal-martin.fr designates 91.121.85.26 as permitted sender) X-PHP-List-Original-Sender: mailing@pascal-martin.fr X-Host-Fingerprint: 91.121.85.26 ns362529.ip-91-121-85.eu Received: from [91.121.85.26] ([91.121.85.26:48415] helo=pascal-martin.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 64/79-32582-1A26FE45 for ; Thu, 26 Feb 2015 13:14:59 -0500 Received: from [192.168.10.8] (teaebook.pck.nerim.net [213.41.140.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pascal-martin.fr (Postfix) with ESMTPSA id CD330E0F4F for ; Thu, 26 Feb 2015 19:14:54 +0100 (CET) Message-ID: <54EF629E.3000306@pascal-martin.fr> Date: Thu, 26 Feb 2015 19:14:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [VOTE] Expectations From: mailing@pascal-martin.fr ("Pascal MARTIN, AFUP") Le 19/02/2015 10:09, Joe Watkins a écrit : > > The expectations RFC is now in voting phase: > https://wiki.php.net/rfc/expectations#vote > Hi, While talking about this RFC with other people of AFUP, we discussed about assert()... And mostly ended up against "it". Still, note we probably discussed more about the idea of using assert() itself than about the RFC and the proposition of improving the existing assert() construct -- which means we probably didn't really answer the question that was asked here. Basically, the idea of adding code (assertions) directly into the code of our application in order to test for "things" doesn't feel right: we'd rather use (unit-)tests for that, alongside our application's code and not interleaved with it. Considering this, we kind of felt it wasn't really necessary to work on assertions and that enhancing them might encourage people to use them more -- adding more non-production code in the middle of the production-code. Also, using .ini directives to enable or disable the execution of portions of code comes with a risk: there is always a chance someone will mis-configure a server and assertions will run in production environment. Or maybe in some edge cases, an assertion could have some side-effect that would impact the code (even if it should not), making it work in development and not work in production? I hope I summarized our thoughts right -- and sorry if we didn't really answer the question that was asked. Thanks for your work! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/