Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91310
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
To: Colin O'Dell <colinodell@gmail.com>, internals@lists.php.net
References: <CAJaRsPv_XDWcBgdiqJXNrzwEds6Y_JyadXv9txjNvAc3FPZd3g@mail.gmail.com>
Message-ID: <56C666F3.3080607@php.net>
Date: Fri, 19 Feb 2016 01:50:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CAJaRsPv_XDWcBgdiqJXNrzwEds6Y_JyadXv9txjNvAc3FPZd3g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
From: francois@php.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=)

Hi,

Le 18/02/2016 20:10, Colin O'Dell a écrit :
> 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 quick
> search of several major projects and libraries and found that only a couple
> 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 not
> cause any loss of functionality.  Yes, it's a BC break, but developers can
> 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
>

Writing an RFC about it is fine, but, IMHO, it should target version 8.0.

As it was already said, deprecating it in 7.x would be probably more 
negative than positive. But, deciding today that it will be suppressed 
in 8.0, and leaving 5 years for devs to adapt their code, is something I 
would probably support.

When discussing about PHP 7, we found a lot of changes that would have 
been possible only if they had been announced several years in advance. 
That's why I think that, even if we just released version 7, we can 
start discussing such changes for 8.0.

Regards

François