Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80737 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84543 invoked from network); 18 Jan 2015 12:23:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Jan 2015 12:23:54 -0000 X-Host-Fingerprint: 80.177.120.119 marston-home.demon.co.uk Received: from [80.177.120.119] ([80.177.120.119:12420] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EC/EA-18613-9D5ABB45 for ; Sun, 18 Jan 2015 07:23:53 -0500 Message-ID: To: internals@lists.php.net References: <0DD30A0D-E7CA-4150-83E0-8FD46635279C@ajf.me> <8761c6280g.fsf@margaine.com> <54B91D16.70901@gmail.com> <78.22.47555.7C24AB45@pb1.pair.com> <1421519637.40188.1.camel@proposaltech.com> <54BABA93.9070809@gmail.com> In-Reply-To: <54BABA93.9070809@gmail.com> Date: Sun, 18 Jan 2015 12:23:49 -0000 Lines: 6 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") "Rowan Collins" wrote in message news:54BABA93.9070809@gmail.com... > >On 17/01/2015 18:33, Todd Ruth wrote: >>> As already mentioned I think as an end result we shouldn't have two >>> >ways to define constructors. Given that PHP already prefers the >>> >new-style constructors I've proposed that we work towards dropping the >>> >old-style, it's just down to a matter of how. >> I've been following these threads for about 10 years and beg that php >> internals continues to "live and let live". >> There have been many, many threads over the years from what I would call >> (with obvious bias) "OO fundamentalists". They seem to be at war with >> code that is "bad form". > >This is an argument that comes up a lot, and it has some merit, sometimes. > >I don't think using __construct over named-method for constructors really >has anything to do with "OOP fundamentalism"; it was a design change to >make certain things simpler (like parent::__construct), This problem is partly solved in the RFC for Default Constructors (see https://wiki.php.net/rfc/default_ctor). If this were extended to cope with PHP 4 style constructors as well then all the problems would be solved. Then there would be no need to remove PHP 4 constructors at all. > and more consistent (all reserved magic methods begin with __, so any > method not beginning with that is safe to use however you like). > >> In the global cost/benefit analysis I don't see that the >> benefits of purifying OO outweigh the costs. > >Not everything is a matter of code style - supporting legacy features comes >at a cost in complexity, All compilers are complex beasts - that is the nature of compilers. If you cannot handle that complexity you shouldn't be working on a compiler. > and sometimes even performance. Whenever new features are added - such as > the ability to call parent::__construct when the parent doesn't declare a > constructor explicitly - decisions have to be made on how they interact > with old features - such as PHP4-style constructors. And simply by having > an accumulation of old features, the codebase is larger, harder to > understand, harder to change, and has more surface area for bugs. Removing long-standing features for no good reason (and a change in style is never a good reason) does nothing more than frustrate all those 240 million website owners who find that their existing applications will no longer run. This is the primary reason why there is a slow adoption rate for each new release. If you stop breaking the language then the adoption rate will be quicker. >Deprecating a feature or raising an E_STRICT doesn't, of course, reduce >this complexity by itself - indeed, it slightly increases it - but it paves >the way for a future version to decide that this feature is no longer >supported, and can be removed in order to improve the rest of the engine. > >So, you are quite right to highlight the costs of doing this, and they may >well outweigh the benefits in this case. However, you are wrong to assume >that the only benefit to be weighed is "purifying OO". Yet the reasons I have seen for removing an existing feature are rarely to fix a problem but to make the language "cleaner" or "more consistent". What this means in reality is "PHP would be cleaner if it didn't contain all those features that I don't like and I don't use, and I don't want anybody else to use them either". >Regards, > -- Tony Marston