Dear Internals,
I have moved the RFC for removing PHP 4 constructors1 into voting
phase. As there are a lot of RFCs in discussion and voting right now I
will leave this RFC in voting phase until the evening (UTC-7) of March
6th which is 12 days away; this will hopefully allow everyone to be
able to review this RFC and vote on it without being rushed.
Cheers,
Levi Morrison
Hi Levi,
I have moved the RFC for removing PHP 4 constructors[1] into voting
phase. As there are a lot of RFCs in discussion and voting right now I
will leave this RFC in voting phase until the evening (UTC-7) of March
6th which is 12 days away; this will hopefully allow everyone to be
able to review this RFC and vote on it without being rushed.
This may be a bit off topic. During this RFC discussion, I mentioned Trait
method
name issue that trait method which has PHP4 constructor name for the class
is
treated as class constructor.
http://3v4l.org/gHbdq (Trait method is called as constructor)
If there is __construct() in the class
http://3v4l.org/HEBMl (Fatal error: A has colliding constructor definitions
coming from traits)
Is this bug fixed also? Or we have to wait until PHP8?
Regards,
P.S. I voted for "yes", of course.
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Levi,
I have moved the RFC for removing PHP 4 constructors[1] into voting
phase. As there are a lot of RFCs in discussion and voting right now I
will leave this RFC in voting phase until the evening (UTC-7) of March
6th which is 12 days away; this will hopefully allow everyone to be
able to review this RFC and vote on it without being rushed.This may be a bit off topic. During this RFC discussion, I mentioned Trait
method
name issue that trait method which has PHP4 constructor name for the class
is
treated as class constructor.http://3v4l.org/gHbdq (Trait method is called as constructor)
If there is __construct() in the class
http://3v4l.org/HEBMl (Fatal error: A has colliding constructor definitions
coming from traits)Is this bug fixed also? Or we have to wait until PHP8?
Aside from the new warning that is emitted and the old one that is
removed no other behavior is changed. This means the "bug" will remain
through the PHP 7 lifecycle even if this RFC passes. If the RFC passes
the colliding constructor issue will be removed in PHP 8 when the rest
of the old-style constructor support is removed.
Hi Levi,
Aside from the new warning that is emitted and the old one that is
removed no other behavior is changed. This means the "bug" will remain
through the PHP 7 lifecycle even if this RFC passes. If the RFC passes
the colliding constructor issue will be removed in PHP 8 when the rest
of the old-style constructor support is removed.
Thank you for the answer.
Everyone should vote "yes" for this RFC.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Le 23/02/2015 05:39, Levi Morrison a écrit :
I have moved the RFC for removing PHP 4 constructors[1] into voting
phase.
Hi,
After discussing this RFC with other people at AFUP, we would be on the
+1 side, especially with the approach that goes in two steps, targeting
both PHP 7 and PHP 8.
We would have been farther from a consensus with the "remove from PHP 7"
idea -- but going in two steps, the first one being to mark those
old-type constructors as deprecated, feels much better.
Thanks for you work!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/