Wouldn't this one change render all code in PEAR as broken? Is the gain
really worth it?
I understand PEAR is basically dead anyways, but for better or worse
there is still a boat load of code that is being used from it (much of
which lacks decent alternatives), and as other people mentioned such a
BC break is likely to add years to the adoption of PHP7, which doesn't
do anyone any good.
On 01/15/2015 08:39 AM, Matteo Beccati wrote:
Hi everyone,
I am proposing an RFC[1] to remove PHP 4 constructors in PHP 7. If
accepted, methods with the same name as their defining class will no
longer be recognized as constructors. As noted in the RFC, there are
already many situations where we do not recognize these methods as
constructors, such as in namespaces and traits and when `function
__construct` is also present.
Andrea Faulds has kindly written a utility that identifies when a PHP
4 constructor is defined[2]. It does not automatically change the code
for liability reasons. The utility PHPMD[3] can also detect this but
has a false positive when `__construct` is also defined.
I still think this (and other) BC breaks should be avoided if we want to
maximize PHP7 adoption, but I've started working on this:
https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/970
which is a patch to php-cs-fixer that would be helpful to ease my (and
other's) pain in case the RFC passes.
I've tried using Andrea's own work and nikita's php-parser and good
results quickly, but ended up switching due to the lack of whitespace
support.
Cheers
--
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
