Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80579
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <CAFMT4Nq1X0bONCs=TJyjB1vZ=+UEnX0L8pSex5fWfUMssh4ktQ@mail.gmail.com>
Date: Thu, 15 Jan 2015 17:21:27 +0000
Cc: internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <1F81DF34-0811-4E71-A5F3-DFAD4B431B66@ajf.me>
References: <CAFMT4NpJxuuqc-wTr1aE4K+wZBT8+04j+9-SsY+nhUMU83fDUg@mail.gmail.com> <0DD30A0D-E7CA-4150-83E0-8FD46635279C@ajf.me> <CAFMT4Nq1X0bONCs=TJyjB1vZ=+UEnX0L8pSex5fWfUMssh4ktQ@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Subject: Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
From: ajf@ajf.me (Andrea Faulds)

Hey Levi,

> On 15 Jan 2015, at 17:16, Levi Morrison <levim@php.net> wrote:
>=20
> On Thu, Jan 15, 2015 at 9:55 AM, Andrea Faulds <ajf@ajf.me> wrote:
>>=20
>> A better solution, IMO, might be simply to add a deprecation notice. =
This would make it obvious during development if you=E2=80=99ve =
accidentally defined a PHP4 constructor, and would encourage migration =
away from them, but wouldn=E2=80=99t prevent existing code from working.
>=20
> Possibly. The reality of my position is that I am unhappy about our
> current constructor situation. Having `__construct` and only
> half-heartedly supporting old-style constructors for the next several
> years (maybe ten?) does not sound good at all.

I agree, it doesn=E2=80=99t. Unfortunately, I=E2=80=99m not sure if we =
have much choice here.

> Removing one of the constructors is a nicer end product than fully
> supporting both, in my opinion, which is why I proposed dropping it. I
> was hoping that a deprecation notice in 5.7 would be sufficient along
> with other standard migration tools and documentation, but since we
> have decided to not release 5.7 perhaps a deprecation would be better.
>=20
> At the same time I'm not thrilled about the amount of deprecation
> notices that could be generated if this is really as common as people
> seem to make it. I generally don't see these older constructors, but
> it seems when people have them they have *a lot* of them.

Yeah, I=E2=80=99m wondering about that. I imagine that a single request =
would probably result in a massive spew of E_DEPRECATEDs, and that=E2=80=99=
s not good. :/

> I was okay
> with this in a theoretical 5.7 release to ease migration because it
> had a fixed lifespan of one release cycle but in version 7 it will
> stay for the duration of all PHP 7 releases.
>=20
> What do you guys think?

I wonder if we could hopefully get rid of them for PHP 8 or something, =
since it=E2=80=99s deprecated=E2=80=A6 but then, if we don=E2=80=99t get =
rid of them now, we might never.

I=E2=80=99m not sure, really.

--
Andrea Faulds
http://ajf.me/