Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79044
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
Message-ID: <1416502819.15061.38.camel@kuechenschabe>
To: Levi Morrison <levim@php.net>
Cc: Alain Williams <addw@phcomp.co.uk>, internals <internals@lists.php.net>
Date: Thu, 20 Nov 2014 18:00:19 +0100
In-Reply-To: <CAFMT4NoHNKHmck_rkAEWo9zx8A1Z5d_pTtaC+jOGXqV7SxkUAQ@mail.gmail.com>
References: 
	<CAFMT4NpJxuuqc-wTr1aE4K+wZBT8+04j+9-SsY+nhUMU83fDUg@mail.gmail.com>
	 <546C9E22.6090301@fedoraproject.org> <20141119134632.GV2294@phcomp.co.uk>
	 <546CA8C0.1060707@gmail.com> <20141119143329.GX2294@phcomp.co.uk>
	 <1416476628.15061.4.camel@kuechenschabe>
	 <CAFMT4NoHNKHmck_rkAEWo9zx8A1Z5d_pTtaC+jOGXqV7SxkUAQ@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: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Thu, 2014-11-20 at 09:11 -0700, Levi Morrison wrote:
> > So I'm -1 on this.
> 
> I just want to make sure I understand you correctly: you are saying
> you are voting no on this RFC because a tool, which is not part of
> this RFC but we kindly provide, doesn't detect when a certain thing is
> called?

It is a non-trivial change. Fixing this is not always as some people
might suggest. If we like it or not there is tons of code out there
depending on this feature. Breaking code, which worked for 15 years,
where we even distribute such code in our main distribution (pear.phar
is full of it) is not an option.

And it is not only PHP - just looked at wordpress and there are quite a
few classes in there where PHP 4 style ctors are used.and which aren't
marked final/public and as such are part of the API, meaning that WP
modules might depend on that. Consequence there is that once the feature
is removed WP users need a new major WP version and new versions of
modules before they can upgrade. This will lead to very slow adoption of
a new PHP version.

We can deprecate it in 7 (and fix code in our distribution) and then
take a next step in a later version, though. This gives folks like WP
time to update their codebase and be ready when our larer version comes
out.

johannes