PHP RFC: "var" Deprecation
- Date: 2016-03-10
- Author: Colin O'Dell colinodell@php.net
- Status: Declined
- Discussion: http://markmail.org/message/523vpfo2q5dwqyed
Introduction
This RFC proposes that var
be deprecated in PHP 7.1 (in favor of public
) and its functionality removed in PHP 8.0.
var
would remain a reserved word in PHP 8.0 for potential future usage.
An upgrade tool is provided to automatically replace all instances of var
with public
. Code modified with this tool would be fully compatible with PHP 5, 7, and 8.
Background
var
is currently a simple alias for public
. However, public
provides more functionality than the limited subset that var
supports. Because var
only offers a duplicate yet limited subset of functionality, this RFC proposes the deprecation of var
in favor of public
.
PHP 4 introduced the var
keyword as the only means to declare class properties. Later on PHP 5 added the public
, protected
, and private
keywords for declaring these properties with a certain visibility level. To quote the documentation:
“The PHP 4 method of declaring a variable with thevar
keyword [was] supported for compatibility reasons (as a synonym for thepublic
keyword)”
(emphasis added)
This alias was left intact for PHP 7.
public
, protected
, and private
can also be used to declare static members and constants (coming in PHP 7.1) whereas var
cannot.
Pros
Removes Duplication
This will eliminate duplicate functionality in the language. Both var
and public
behave identically for non-static member variables and therefore both are not technically needed (other than for backwards-compatibility).
''public'' Is More Useful
The only functional difference between var
and public
is that the latter also supports static members and constants (coming in PHP 7.1):
<?php class Example { public $foo; // Works public static $foo; // Works public const FOO // Works var $foo; // Works var static $foo; // Doesn't work var const FOO; // Doesn't work }
var
is therefore a limited subset of public
.
Ample Warning
PHP 8.0 is likely several years away. Deprecating this now (rather than later) would provide developers with sufficient notice that their code may need to be modified to work on 8.0.
Easy Upgrade Path
Because var
is currently an alias for public
, updating older code is as simple as replacing var
with public
everywhere it appears. A utility script has been provided with this RFC to aid with the transition.
Removes Legacy Functionality
var
is a legacy feature from PHP 4 which has been superseded by the visibility keywords. It was kept in PHP 5+ for backwards-compatibility. Removing it would help clean up the lesser-used legacy bits of the language.
There is precedent for deprecating and eventually removing other legacy features (with modern equivalents) as part of major releases:
Low Usage
The top 10,000 packages on Packagist were analyzed (along with their dependencies) to determine the proliferation of var
in the PHP ecosystem:
% | Description | Number of Packages |
---|---|---|
62% | Use public only | 6,221 |
27% | Don't use public variables of any kind | 2,665 |
4% | Use var internally | 448 |
4% | Have a dependency which uses var | 352 |
3% | Failed to be analyzed due to misc. errors in the survey tool | 335 |
Because dependencies may have already been counted as “packages using var
internally”, the true utilization is somewhere between 4 and 8%.
The total number of public
and var
keywords were counted across every file of every package (including dependencies which may be counted multiple times):
- 94% -
public
(1,650,084 instances) - 6% -
var
(98,745 instances)
The following packages are the “worst offenders”, making up 62% of the total number of var
keywords found:
- 22% - simpletest (22,116 instances)
- 17% - phpseclib (16,648 instances)
- 14% - mpdf (14,000 instances)
- 9% - simplepie (8,745 instances)
Updating these packages would drop overall var
utilization to 1.5 - 3.0%.
This survey confirms that modern PHP development has largely moved away from var
. Accepting this RFC will therefore have minimal impact on the ecosystem.
Cons
It's Not Broken
There are no technical issues with the current implementation of var
and therefore no urgency to remove it.
Breaks Backwards Compatibility
PHP 4 classes will no longer function as-is in PHP 8.0. Furthermore, any classes written in PHP 5.x or 7.x may also break in 8.0 if they use var
. BC breaks should not be taken lightly.
No Functionality Benefit
This change does not introduce any new functionality for developers. Those who are not using var
will see no impact. Those who do use var
will need to update their code.
''public'' Is Not The Same
Some developers do not feel comfortable replacing var
with public
because they did not intend for those variables to explicitly be public. Although replacing var
with public
does result in the same functionality, it may unintentionally imply that those variables were explicitly intended to be public (which may not be the case).
Backward Incompatible Changes
PHP 7.1 - 7.x: usages of var
will raise a deprecation notice but otherwise work as-is.
PHP 8.0: Usages of var
will throw a parse error.
Upgrade Tool
An upgrade tool is provided which automatically replaces all instances of var
with public
. Code modified with this tool should be fully-compatible with PHP 5, 7, and 8.
RFC Impact
To SAPIs
None
To Existing Extensions
?
To Opcache
?
Future Scope
Reserving the var
keyword will allow it to be used for new functionality in 8.0 and beyond.
Vote
The vote is a simple Yes/No on whether to deprecate var
in PHP 7.1 and remove its functionality from 8.0 (but reserve the keyword for future usage).
As this is a language change, this RFC requires a 2/3 majority to pass.
Voting started on 2016-03-24 and will end on 2016-03-31 at 12:30 UTC.
Patches and Tests
- https://github.com/php/php-src/compare/master...tpunt:deprecate-var (Created by Thomas Punt)