On 20 November 2014 20:54:00 GMT, Levi Morrison <le...@php.net> wrote: >>> 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…
The problem is that the constructor is part of the public API (for inheritance purposes) so the required refactoring is not necessarily isolated to one project, or even doable by one developer. The maintainer of the library must first release a version with the new constructors in place, and the consumer of the library must then audit their code for anything relying on the old constructor. Supporting various combinations of PHP 5/7, old/new lib, and old/new consumer code is then messy at best. I agree that it's perfectly doable, but it's not as easy to migrate as, say, a syntax change. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
