Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85004 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 20087 invoked from network); 16 Mar 2015 08:48:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Mar 2015 08:48:39 -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.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:48540] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 43/F2-00492-5E896055 for ; Mon, 16 Mar 2015 03:48:38 -0500 Received: (qmail 3796 invoked by uid 89); 16 Mar 2015 08:48:34 -0000 Received: by simscan 1.3.1 ppid: 3790, pid: 3793, t: 0.0809s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@86.178.189.108) by mail4.serversure.net with ESMTPA; 16 Mar 2015 08:48:34 -0000 Message-ID: <550698E2.8060802@lsces.co.uk> Date: Mon, 16 Mar 2015 08:48:34 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: internals@lists.php.net References: <54FF8CED.5030701@gmail.com> <54FFC96D.6090004@gmail.com> <1579682575.9673.1426064704052.JavaMail.open-xchange@app06.ox.hosteurope.de> <55000A88.1030909@lsces.co.uk> <55060A95.1020901@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV][RFC][DISCUSSION] Strict Argument Count From: lester@lsces.co.uk (Lester Caine) On 16/03/15 03:29, Yasuo Ohgaki wrote: > > I agree partly. It does not provide any additional feature. > However, it gives users ability to detect bugs. It's important gain for > users also. > > Wrong code should be fixed anyway. The RFC could be more old code friendly > if E_DEPECATED is used. The problem here is simply that just what error's are enabled and disabled is getting more difficult to decide? If when moving from a currently clean environment which has every error displayed and only shows something when any problem arises then moving to a new major version do we have to switch everything off again since all types of errors will now be thrown by the previously clean code. This is the problem currently in the PHP5.2->5.4 dilema. Yes you can switch errors off and the code runs, but then how do you address the problems. Added to which something hidden by E_DEPECATED in 5.3 is now no longer available in 5.4, but the code is still 5.2. Adding the errors is not really the problem it's working out the order they need to be cleared in :( -- 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