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 enough
> to fix our legacy codebases to replace PHP4-constructors. That is certainly
> 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", which
> 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 work
> 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=21058930#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).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
