Dear Internals,
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.
Cheers,
Levi Morrison
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/
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
Hi Levi,
On Sat, Feb 7, 2015 at 7:05 AM, Levi Morrison morrison.levi@gmail.com
wrote:
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.
I thought I filed this as Trait bug, but it isn't the bug db. I might
forget to report it.
Class calls trait function that is PHP4 constructor.
This could be resolved by removing PHP4 constructor.
Could this issue be resolved in PHP7?
Even if previous issue could be resolved, we have
PHP4 constructor is harmful.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net