rfc:var_deprecation

This is an old revision of the document!


PHP RFC: "var" Deprecation

Introduction

var is currently a simple alias for public. Both keywords provide identical functionality. This RFC therefore 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 the var keyword [was] supported for compatibility reasons (as a synonym for the public keyword)”

(emphasis added)

This alias was left intact for PHP 7.

Proposal

This RFC proposes that var be deprecated in PHP 7.1 and its functionality removed in PHP 8.0.

var would remain a reserved word in PHP 8.0 for potential future usage.

Pros

Removes Duplication

This will eliminate duplicate functionality in the language. Both var and public behave identically and therefore both are not technically needed (other than for backwards-compatibility).

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.

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:

Ample Warning

PHP 8.0 is at least a few 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.

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.

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.

RFC Impact

To SAPIs

?

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.

Proposed Voting Choices

As this is a language change, this RFC requires a 2/3 majority to pass.

Patches and Tests

No patch has been created yet. Assistance would be greatly appreciated.

References

rfc/var_deprecation.1456189438.txt.gz · Last modified: 2017/09/22 13:28 (external edit)