Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80687 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 55141 invoked from network); 17 Jan 2015 10:58:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Jan 2015 10:58:09 -0000 X-Host-Fingerprint: 80.177.120.119 marston-home.demon.co.uk Received: from [80.177.120.119] ([80.177.120.119:29802] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AC/11-47555-0404AB45 for ; Sat, 17 Jan 2015 05:58:08 -0500 Message-ID: To: internals@lists.php.net References: <0DD30A0D-E7CA-4150-83E0-8FD46635279C@ajf.me><8761c6280g.fsf@margaine.com><54B91D16.70901@gmail.com> In-Reply-To: Date: Sat, 17 Jan 2015 10:57:17 -0000 Lines: 1 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Newsreader: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 X-Posted-By: 80.177.120.119 Subject: Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors From: TonyMarston@hotmail.com ("Tony Marston") "Stelian Mocanita" wrote in message news:CAMc0WS5LpdVqF_5P8UiWBzuQc+maX+Shmmi8pZLgGRfOJ7aEmg@mail.gmail.com... > >Florian Margaine wrote on 16/01/2015 13:01: > >Hi Stelian, >> >> Stelian Mocanita writes: >> >> Not under active development doesn't mean that the application shouldn't >> be able to upgrade PHP and enjoy the bug/security fixes or performance >> improvements that new versions provide. I agree. If the core developers want each new release, with its bug fixes and security enhancements, to be adopted by the community then they should stop breaking BC for no good reason. >Completely agree, but you get once in N years a chance to do some cleanup >on the language. If people expect no BC breaks on major versions, when is >the time for the cleanup? It is one thing to remove functionality from the core if it a security issue or it causes bugs, but people's definitions of "clean" are many and varied, so using that as an excuse to break the language will not down well with those millions of website owners whose applications suddenly stop working after an upgrade. By "clean" it is obvious that you mean "style" as in "don't do it like that, do it like this". It is not up to the core developers to dictate style on the rest of the programmer community - you provide the basic tools, and it is up to the individual programmer to decide what functions to use in order to solve the problem at hand. Programming style is the prerogative of the individual programmer, or a team of programmers, and should never be dictated by any outside agency. >That's one thing. The other thing is that there's a flow in your logic. If >you want the bug/security/performance fixes, it means you are already >running latest stable and for some reason you completely ignored all of the >deprecation warnings until now. I think we can both agree on this being a >bit far-fetched. I am using PHP 5.6.4 with error_reporting=E_ALL and I am not seeing any messages regarding my use of PHP 4 constructors. They are also NOT marked as deprecated in the manual. If they are not marked as deprecated then you cannot suddenly remove them. Besides, what problem(s) would be solved by removing PHP 4 constructors? If there are no problems then removing them would not only NOT solve any problem it would actually create a HUGE problem for all those applications which still use them. >Not to mention that all the old ctor fatal errors can be fixed with an >automated scripts that replaces the old ctors with the new ones. > >Stelian -- Tony Marston