Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82372
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54D613F2.1040901@beccati.com>
References: <CAFMT4Nr=Dk1Y6DFw5iftsaLHF9QkNMCJrxJGb66_rpYN3Px8UA@mail.gmail.com>
	<54D613F2.1040901@beccati.com>
Date: Tue, 10 Feb 2015 13:16:20 +0100
Message-ID: <CAH-PCH599ZUmSpvfob_E_apD=2wBg2OJBFBDzRg9_dTVR=frow@mail.gmail.com>
To: Matteo Beccati <php@beccati.com>
Cc: Levi Morrison <morrison.levi@gmail.com>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bb04876ccea06050ebada2c
Subject: Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors Update
From: tyra3l@gmail.com (Ferenc Kovacs)

--047d7bb04876ccea06050ebada2c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 7, 2015 at 2:32 PM, Matteo Beccati <php@beccati.com> wrote:

> Hi Levi,
>
>  I have updated the RFC for removing PHP 4 constructors[1]. Notably, I
>> have pushed off the removal to PHP 8, and instead only deprecate them
>> in PHP 7. The rationale is that eventual consistency in this matter is
>> good enough for now, and going slow may help avoid a Python 2 vs 3
>> type disaster where older libraries aren't updated fast enough.
>>
>> I intend to put this to vote soon, as we are approaching the March
>> feature freeze, so please chime in if you have been wanting to voice
>> your opinion and haven't.
>>
>
> Over-long email - sorry about it! ;)
>
> I strongly opposed this RFC in past. I've also seen people suggesting to
> grumpy old men like me that the time spent complaining was probably enoug=
h
> to fix our legacy codebases to replace PHP4-constructors. That is certain=
ly
> not true in my case, but I've decided to accept the challenge and build a
> tool to convert PHP4-constructors to __construct, automating the required
> tasks as much as possible. Such work is an ongoing PR to PHP-CS-Fixer[1],
> which will hopefully be merged in the next few weeks.
>
> I've advertised it before, but I'd like to do it again, as I think it
> greatly reduces the impact of the BC break of your RFC.
>
> I've ran it on the (legacy) open source application I maintain and it
> detected and converted most of the classes[2]: 962 changed files with 351
> additions and 884 deletions. The only manual changes I had to do were
> fixing a few calls to the grandparent constructors[3].
>
> What I can tell from this experience is that dropping PHP4-constructors
> shouldn't be quite as bad as I thought it was, at least now that there's =
a
> tool that does most of the job for you. Adapting (all of) PEAR should be
> fairly straightforward in case someone is willing to do that.
>

thanks for looking into this and taking your time to help with the
migration!


>
> The real challenge I will have to face in the future is the removal of
> "Scoped calls of non-static methods from incompatible $this context", whi=
ch
> has been applied and temporarily reverted soon after. Many PEAR (and
> possibly non-PEAR) classes in our codebase have methods that have been
> designed to work both as static/non-static methods[4] which won't soon wo=
rk
> any more in PHP7. Granted, I've voted "yes" on this one and I still would
> today, but I'd expect that fixing that code once the "revert is reverted"
> is going to be much trickier than just renaming a bunch of constructors.
>

we discussed this related to PEAR and Nikita agreed that the original
implementation of the removal was too strict:
http://chat.stackoverflow.com/transcript/11?m=3D21058930#21058930
and he even come up with an alternative solution:
https://github.com/php/php-src/pull/1026
(not sure why didn't he merged or announced it for discussion yet).

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--047d7bb04876ccea06050ebada2c--