Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80587
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain snappymail.ca designates 50.97.106.214 as permitted sender)
Message-ID: <54B8249D.2050101@snappymail.ca>
Date: Thu, 15 Jan 2015 12:35:41 -0800
Reply-To: ipso@snappymail.ca
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAFMT4NpJxuuqc-wTr1aE4K+wZBT8+04j+9-SsY+nhUMU83fDUg@mail.gmail.com> <54B7ED3A.6090805@beccati.com>
In-Reply-To: <54B7ED3A.6090805@beccati.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
From: ipso@snappymail.ca (Mike)

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