Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91333
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAJaRsPv_XDWcBgdiqJXNrzwEds6Y_JyadXv9txjNvAc3FPZd3g@mail.gmail.com>
References: <CAJaRsPv_XDWcBgdiqJXNrzwEds6Y_JyadXv9txjNvAc3FPZd3g@mail.gmail.com>
Date: Fri, 19 Feb 2016 17:27:28 -0400
Message-ID: <CAOsHV+tqFaER-USFv8TbAC+U5k=Hi8mzvX8S-nzvwot949kvuw@mail.gmail.com>
To: "Colin O'Dell" <colinodell@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
From: marcio.web2@gmail.com (Marcio Almada)

Hi!

2016-02-18 15:10 GMT-04:00 Colin O'Dell <colinodell@gmail.com>:
> Hello everyone,
>
> I'd like to propose an RFC to deprecate and eventually remove the "var"
> keyword.
>
> My understanding is that this keyword was kept in PHP 5 for
> backwards-compatibility with PHP 4.  However, it's been 9 years since PHP=
 4
> was discontinued, so I'd like to bring this topic up for review.
>
> Usage of "var" doesn't seem to be as widespread recently. I've done a qui=
ck
> search of several major projects and libraries and found that only a coup=
le
> are using it.  I personally haven't seen it used in any PHP 5.3+ project
> I've worked on in recent memory.
>
> Because "var" simply acts as an alias for "public", removing it should no=
t
> cause any loss of functionality.  Yes, it's a BC break, but developers ca=
n
> easily replace it with "public" to maintain the same functionality.
>
> PHP 7 deprecated PHP 4 style constructors in favor of the PHP 5
> __construct() method.  I'd like to propose doing the same for the "var"
> keyword - deprecate it in PHP 7.1 and remove it in a future version (7.2 =
or
> 8.0?)
>
> I'd appreciate any thoughts or feedback you may have, especially if you
> have any objections to me creating an RFC for this proposal.
>
> Best regards,
>
> Colin O'Dell

I'm +1 on this for all the reasons mentioned above. There is plenty of
time for people to update and, additionally, an automated patch script
could be provided along with the RFC.

Thank your for taking the time discuss on this mailing list.

M=C3=A1rcio Almada.