On Sat, Feb 7, 2015 at 2:32 PM, Matteo Beccati <p...@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
