Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80703
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain proposaltech.com does not designate 216.109.115.212 as permitted sender)
Message-ID: <1421519637.40188.1.camel@proposaltech.com>
To: Levi Morrison <levim@php.net>, Tony Marston <TonyMarston@hotmail.com>, 
	internals <internals@lists.php.net>
Date: Sat, 17 Jan 2015 10:33:57 -0800
In-Reply-To: <CAFMT4NrH+=6B4=kVyrmW1Oc0N-_ONNdjaWK0xZCXDVnV_pn-Nw@mail.gmail.com>
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>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
From: truth@proposaltech.com (Todd Ruth)

On Sat, 2015-01-17 at 10:56 -0700, Levi Morrison wrote:
> >> We are talking about something deprecated since 10 years, about the 1st
> >> major release in a decade, something we will use for the next 12-14 years.
> >
> >
> > That is the point - PHP 4 constructors have NOT been marked as deprecated in
> > the manual, and they produce no warnings at runtime.
> >
> > If they have not been marked as deprecated then you cannot suddenly remove
> > them.
> 
> Warning: a long response with code snippets/
> 
> [ Snipped examples of mixing constructor flavors / namespaces ]
> 

> Then there are no warnings of any kind (since PHP 5.3.2), and
> __construct is used as the constructor. The method test is just a
> normal method.
> 
> To me this clearly indicates three things:
> 
>   1. Having both forms of constructors is bad form (hence the E_STRICT)
>   2. When both are present the new-style __construct is used over the
> old-style PHP 4 constructor, meaning the language prefers
> __constructor.
>   3. Old-style constructors don't exist in namespaces. Notably this
> was a conscious choice as evidenced by behavior that existed in PHP
> 5.3.0 - 5.3.2 where the E_STRICT was emitted like non-namespaced code.
> 
> This is the behavior of shipped, stable versions of PHP. I think it's
> a bit illogical to conclude that just because there aren't any
> E_DEPRECATED warnings emitted in PHP 5 that old-style constructors are
> fully supported.
> 
> That leaves us realistically with four options:
> 
>   1. Bring full support for PHP 4 constructors
>   2. Emit E_DEPRECATED when PHP 4 constructors are used
>   3. Drop support for PHP 4 constructors so they are just normal
> methods, just as they are in namespaces
>   4. Maintain current behavior.
> 
> 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".  Fortunately, most of their victories to date
have been in the form of adding "E_STRICT"s.  There seems to be a
compromise in the community that we won't break people's code, but we'll
let them know when they are using bad form code.  I believe that's
reasonable.
Please don't construe the willingness to add E_STRICTs with agreement
that such code should be forcibly eliminated.  If there were a fully
automated tool to bring code into compliance, I would feel a lot better
about such changes, but even then, many of us would be applying that
tool to third-party code that has been lying around for a decade
untouched, and that's scary.

I suppose my opinion on these things is formed by my life experience
with these issues and since I don't doubt we all mean well, I guess the
OO purists probably are approaching this from different life
experiences.  Here is where I'm coming from:
I've been on my current project for over 10 years.  We have always had a
_very_ small software department.  The code was originally developed in
php4 style using using objects, but not following the purist OO
conventions.  We now have hundreds of thousands of lines of php.  We've
accumulated reliance on many libraries that were written in a variety of
styles and generally we're just glad they work.  I'm sure there is no
active development on many (perhaps most) of them.  To this day, we
still don't use namespaces or exceptions.  We still follow our
conventions for prefixing everything to avoid name collisions.  We don't
have the resources to make major changes without clear benefits to our
users.  (For the record, when we do find an issue with php, we dig in
and try to find a fix and submit it.  We've fixed a couple of things.  I
know it is negligible compared to what most of the folks reading this
do.)

I don't know how common our situation is, but I'm sure there are others
out there.  In the global cost/benefit analysis I don't see that the
benefits of purifying OO outweigh the costs.

Thanks for listening!

- Todd