Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80851
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <0DD30A0D-E7CA-4150-83E0-8FD46635279C@ajf.me>
References: <CAFMT4NpJxuuqc-wTr1aE4K+wZBT8+04j+9-SsY+nhUMU83fDUg@mail.gmail.com>
	<0DD30A0D-E7CA-4150-83E0-8FD46635279C@ajf.me>
Date: Mon, 19 Jan 2015 21:22:30 -0600
Message-ID: <CALrkBjZfeR6tGi9dX8a3JLPiBkfMbCg1Kwj8vZy2d_Puj6kdJg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Levi Morrison <levim@php.net>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1135f140fecf27050d0cf256
Subject: Re: [PHP-DEV] [RFC] Remove PHP 4 Constructors
From: pencap@gmail.com (Mike Willbanks)

--001a1135f140fecf27050d0cf256
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello Andrea,

On Thu, Jan 15, 2015 at 10:55 AM, Andrea Faulds <ajf@ajf.me> wrote:

> Hey Levi,
>
> Upon further thought, I=E2=80=99m not super-enthusiastic about this. As h=
as been
> pointed out, it=E2=80=99s a pretty serious BC break, whether code can be
> automatically updated or not. PHP 4 constructors may be obsolete, but an
> awful lot of code uses them.
>
> 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 d=
efined a
> PHP4 constructor, and would encourage migration away from them, but
> wouldn=E2=80=99t prevent existing code from working.
>
> Thoughts?
>

I would be against a deprecation notice here.  In fact I think it should
either be do nothing or remove them entirely.  I know this thread has
become out of control but as a user of PHP 3, 4 and 5; a framework
developer; and a engineering executive I find that the PHP 4 style
constructors to be an ignorance that I am forced to currently deal with.

The amount of information in this post is vast and I don't feel I need to
go into details.  However, I support this proposal 100% as do I feel most
of the open source community.  Items that are still out there relying on
PEAR and other packages should remain on PHP 5 or even less.  We have
better solutions now such as composer which has changed the ecosystems
reliance on items such as PEAR.

Developers that are relying on PEAR have other issues to date than simply
what would happen with PHP 7 as not all PEAR packages work well with PHP 5
at this time especially the latest releases.  PEAR is a thing that has come
and gone.  Legacy code that still remains with PHP 4 style constructors
should upgrade to the latest.  Language evolve and we need to keep pushing
the bar forward.

As a personal note, PHP has slowly been moving towards the background for
certain applications for JavaScript (nodejs) and I feel for PHP to remain
it's competitive market it needs to evolve more as a leading language.  PHP
was great about this between 3, 4 and 5.  7 must do the same thing
otherwise I feel like it will lead to a slow death much like the perl of
old.

Regards,

Mike

--001a1135f140fecf27050d0cf256--