Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80707
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.171 as permitted sender)
Message-ID: <54BABA93.9070809@gmail.com>
Date: Sat, 17 Jan 2015 19:40:03 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAFMT4NpJxuuqc-wTr1aE4K+wZBT8+04j+9-SsY+nhUMU83fDUg@mail.gmail.com>	 <0DD30A0D-E7CA-4150-83E0-8FD46635279C@ajf.me>	 <CAFMT4Nq1X0bONCs=TJyjB1vZ=+UEnX0L8pSex5fWfUMssh4ktQ@mail.gmail.com>	 <alpine.DEB.2.11.1501161126340.4080@whisky.home.derickrethans.nl>	 <CAMc0WS7MjJ85BTSQcRZtGS5MU_9_DfU95SRh6qkmDgWkS2dO4w@mail.gmail.com>	 <8761c6280g.fsf@margaine.com> <54B91D16.70901@gmail.com>	 <CAMc0WS5LpdVqF_5P8UiWBzuQc+maX+Shmmi8pZLgGRfOJ7aEmg@mail.gmail.com>	 <AC.11.47555.0404AB45@pb1.pair.com>	 <CAEZPtU7zTKZY4=n_pahWeW2G7JANNnrOZWHHz4bcVb-VGFpegA@mail.gmail.com>	 <78.22.47555.7C24AB45@pb1.pair.com>	 <CAFMT4NrH+=6B4=kVyrmW1Oc0N-_ONNdjaWK0xZCXDVnV_pn-Nw@mail.gmail.com> <1421519637.40188.1.camel@proposaltech.com>
In-Reply-To: <1421519637.40188.1.camel@proposaltech.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
From: rowan.collins@gmail.com (Rowan Collins)

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), 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, 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.

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".

Regards,

-- 
Rowan Collins
[IMSoP]