Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:79070 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84552 invoked from network); 21 Nov 2014 09:49:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Nov 2014 09:49:31 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; 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:59179] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D2/D7-32541-8AA0F645 for ; Fri, 21 Nov 2014 04:49:29 -0500 Received: (qmail 28383 invoked by uid 89); 21 Nov 2014 09:49:25 -0000 Received: by simscan 1.3.1 ppid: 28375, pid: 28380, t: 0.0662s 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.177.82.94) by mail4.serversure.net with ESMTPA; 21 Nov 2014 09:49:25 -0000 Message-ID: <546F0AA5.30805@lsces.co.uk> Date: Fri, 21 Nov 2014 09:49:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: internals@lists.php.net References: <546C9E22.6090301@fedoraproject.org> <20141119134632.GV2294@phcomp.co.uk> <546CA8C0.1060707@gmail.com> <20141119143329.GX2294@phcomp.co.uk> <1416476628.15061.4.camel@kuechenschabe> <1416502819.15061.38.camel@kuechenschabe> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors From: lester@lsces.co.uk (Lester Caine) On 20/11/14 21:29, Rowan Collins wrote: > The problem is that the constructor is part of the public API (for inheritance purposes) so the required refactoring is not necessarily isolated to one project, or even doable by one developer. The maintainer of the library must first release a version with the new constructors in place, and the consumer of the library must then audit their code for anything relying on the old constructor. Supporting various combinations of PHP 5/7, old/new lib, and old/new consumer code is then messy at best. > > I agree that it's perfectly doable, but it's not as easy to migrate as, say, a syntax change. I know I sound like a broken record, but this is EXACTLY the same problem as e_strict! It is all very well saying old code can still run if you hide the the warnings and ERRORS, but you have to spend the time fixing each and every warning simply to ensure that it will work on the next release ... hiding things does not work. And I still run my own version of PEAR to get around the e_strict problems! -- 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