morrisonlevi/gist:4e87e6708e65ff1a565c Secret

## gistfile1.txt
>> I just want to make sure I understand you correctly: you are saying
>> you are voting no on this RFC because a tool, which is not part of
>> this RFC but we kindly provide, doesn't detect when a certain thing is
>> called?
>
> It is a non-trivial change. Fixing this is not always as some people
> might suggest.

1) Identify PHP 4 constructors using one of several tools (including upgrading to PHP 5.7 and getting E_DEPRECATEDs).
2) Use one of the several tools that support method rename refactoring (Netbeans, PhpStorm, and others) to rename the methods to __construct.

You could probably automate it with a very high degree of success; I just don't want to automatically change code for liability reasons.  I think you are exaggerating the required work given the tools we have at our disposal…

…but that's okay. You can think and vote however you chose.

> We can deprecate it in 7 (and fix code in our distribution) and then
> take a next step in a later version, though.

I am proposing E_DEPRECATED in PHP 5.7, just as the RFC for using multiple default statements in switches (which was accepted, by the way).

Update to PHP 5.7 first which gives you more time to prepare for this and other BC breaks for PHP 7.
	>> I just want to make sure I understand you correctly: you are saying
	>> you are voting no on this RFC because a tool, which is not part of
	>> this RFC but we kindly provide, doesn't detect when a certain thing is
	>> called?
	>
	> It is a non-trivial change. Fixing this is not always as some people
	> might suggest.

	1) Identify PHP 4 constructors using one of several tools (including upgrading to PHP 5.7 and getting E_DEPRECATEDs).
	2) Use one of the several tools that support method rename refactoring (Netbeans, PhpStorm, and others) to rename the methods to __construct.

	You could probably automate it with a very high degree of success; I just don't want to automatically change code for liability reasons. I think you are exaggerating the required work given the tools we have at our disposal…

	…but that's okay. You can think and vote however you chose.

	> We can deprecate it in 7 (and fix code in our distribution) and then
	> take a next step in a later version, though.

	I am proposing E_DEPRECATED in PHP 5.7, just as the RFC for using multiple default statements in switches (which was accepted, by the way).

	Update to PHP 5.7 first which gives you more time to prepare for this and other BC breaks for PHP 7.