Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94042 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 31751 invoked from network); 16 Jun 2016 09:05:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Jun 2016 09:05:18 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.230 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.230 mail4-3.serversure.net Linux 2.6 Received: from [217.147.176.230] ([217.147.176.230:50767] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CC/D0-25388-CCB62675 for ; Thu, 16 Jun 2016 05:05:17 -0400 Received: (qmail 18112 invoked by uid 89); 16 Jun 2016 09:05:12 -0000 Received: by simscan 1.3.1 ppid: 18078, pid: 18108, t: 0.0844s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 16 Jun 2016 09:05:12 -0000 To: internals@lists.php.net References: Message-ID: <57626BBB.6090407@lsces.co.uk> Date: Thu, 16 Jun 2016 10:04:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Throw Exception on Attempt of Constant Redefinition From: lester@lsces.co.uk (Lester Caine) On 16/06/16 07:44, Dmitry Stogov wrote: > RFC also proposes a way to "fix" affected applications, wrapping constant definitions, that may be redefined, with try/catch. Doesn't anybody remember the problems which STILL have to be resolved with changes in PHP5.2/3/4 which require the assistance of programmers to fix naive users problems. Now many of the new features being added will not be currently used in legacy code, but can anybody ensure that all of the BC changes being currently pushed for will not cause a more general PHP5.4 style block to upgrading? HAVING to add changes to code to retain a legacy style of operation is something that should only happen in a major version. Isn't this why most big projects no longer bother with many small version changes? What is Firefox up to now ... However going down that root does require LTS builds which is something else which is maintaining PHP5.3 in the field. I am now getting used to the changes in PHP7, but the current roadmap for PHP7.1 is just another PHP5.4 in my book and it does create a case for my simply rolling back to PHP5 since none of my production systems have been fully updated so they can use PHP7 yet ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk