Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:49490 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 81636 invoked from network); 24 Aug 2010 13:54:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Aug 2010 13:54:32 -0000 Authentication-Results: pb1.pair.com smtp.mail=adam@adamharvey.name; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=adam@adamharvey.name; sender-id=unknown Received-SPF: error (pb1.pair.com: domain adamharvey.name from 209.85.216.170 cause and error) X-PHP-List-Original-Sender: adam@adamharvey.name X-Host-Fingerprint: 209.85.216.170 mail-qy0-f170.google.com Received: from [209.85.216.170] ([209.85.216.170:54240] helo=mail-qy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 87/C3-60897-71FC37C4 for ; Tue, 24 Aug 2010 09:54:31 -0400 Received: by qyk35 with SMTP id 35so3901987qyk.8 for ; Tue, 24 Aug 2010 06:54:28 -0700 (PDT) Received: by 10.224.53.203 with SMTP id n11mr1078060qag.148.1282658068321; Tue, 24 Aug 2010 06:54:28 -0700 (PDT) MIME-Version: 1.0 Sender: adam@adamharvey.name Received: by 10.229.62.84 with HTTP; Tue, 24 Aug 2010 06:54:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Aug 2010 21:54:08 +0800 X-Google-Sender-Auth: FDqeLN3vleVudU5cTZWQ1PJt2AY Message-ID: To: Pierre Joye Cc: PHP internals Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [PATCH] #52563: Adding E_NONE and/or E_EVERYTHING constants From: aharvey@php.net (Adam Harvey) On 24 August 2010 21:46, Pierre Joye wrote: > I don't see it as an argument against as the fix is rather easy: > > if (!defined('E_NONE')) { > ... > > But it should not be added in a minor release. Agreed. To be clear: the patch is against trunk, and I wouldn't suggest it even be considered for 5.3. Johannes has already said he wouldn't accept it for 5.3 anyway. :) > I would like something like E_DEVELOPMENT (notices, warnings, > deprecated and the classic fatal), to strongly advice developers to > use it. On the same line, we could add E_PRODUCTION to set the error > reporting we recommend in production (fatal and warning). I'd be happy enough with E_DEVELOPMENT instead of E_EVERYTHING. The point is that everything should be on =E2=80=94 we should be encouraging developers to fix up E_STRICT notices as well as the usual array of things E_ALL shows. Of course, another option is to put E_ALL back to truly being "all". Adam