Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78998
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.178 as permitted sender)
MIME-Version: 1.0
Sender: are.you.winning@gmail.com
In-Reply-To: <546CA8C0.1060707@gmail.com>
References: <CAFMT4NpJxuuqc-wTr1aE4K+wZBT8+04j+9-SsY+nhUMU83fDUg@mail.gmail.com>
	<546C9E22.6090301@fedoraproject.org>
	<20141119134632.GV2294@phcomp.co.uk>
	<546CA8C0.1060707@gmail.com>
Date: Wed, 19 Nov 2014 14:41:09 +0000
Message-ID: <CAGAGxbbSdvbAQGB+McW3T_aLf585Dvb9XuGTKMmiTNMkZRKAVg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7ba97632d4a5090508373307
Subject: Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
From: cw@daverandom.com (Chris Wright)

--047d7ba97632d4a5090508373307
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 19 November 2014 14:27, Rowan Collins <rowan.collins@gmail.com> wrote:

> Alain Williams wrote on 19/11/2014 13:46:
>
>> On Wed, Nov 19, 2014 at 02:41:54PM +0100, Remi Collet wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Le 19/11/2014 00:11, Levi Morrison a =C3=A9crit :
>>>
>>>> [1]: https://wiki.php.net/rfc/remove_php4_constructors
>>>>
>>> This will just kill PEAR and most of available libraries on PEAR forge.
>>>
>>> Yes they are still some use of them
>>> Yes keeping PHP 4 for PEAR is a bad idea
>>>
>> Maybe this would spur PEAR to moving to a modern PHP, they could always
>> maintain
>> a separate PEAR legacy. PHP 4 support ended some 6 years ago.
>>
>>
> PEAR is not a single organisation who can mass update all the modules; th=
e
> guidelines could be updated, if they haven't been already, but there woul=
d
> still be a whole repository full of libraries which used this.
>
> Now, whether that's acceptable or not, I don't know, but it does highligh=
t
> the size of the compatibility break.
>

It would be quite easy to write a tool to detect classes that use the old
style, and even automatically fix them in most cases. As BC breaks go, this
is about as minimal as it gets for package maintainers.

Note that, for users who are insane enough to expect to maintain PHP4-7
support in a single codebase, it's also easily possible to work with both
styles even after this change is introduced:

class Foo
{
    function Foo()
    {
        // invoked as the ctor in PHP4
        $this->__construct();
    }

    function __construct()
    {
        // invoked as the ctor in PHP5/7
    }
}

--047d7ba97632d4a5090508373307--