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.
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.
So, given the level of breakages that legacy apps are going to endure
anyway, I'd be ok with this RFC targeting PHP7 too.
Cheers
[1] https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/970
[2] http://qrurl.it/r/kz5
[3] http://qrurl.it/r/kz6
[4] https://github.com/pear/pear-core/blob/stable/PEAR.php#L303
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
