Re: [RFC] Deprecate properties using var
| From: | Andrea Faulds | Date: | Thu, 12 Feb 2015 11:57:23 +0000 |
| Subject: | Re: [RFC] Deprecate properties using var | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-82526@lists.php.net to get a copy of this message | ||
Hi Pierre,
> On 12 Feb 2015, at 11:51, Pierre du Plessis <pierre@pcservice.co.za> wrote:
>
> Before I create an RFC, I just want to get some feedback on a proposal, to
> deprecated the use of "var" when declaring properties on a class.
>
> This was previously deprecated in PHP 5.0.0 and the deprecation notice was
> removed in PHP 5.1.3.
>
> My proposal is to deprecate the use of var on properties in PHP 7, and then
> remove support for it in PHP 8. This compliments the [0] "Remove PHP 4
> Constructors" RFC, as it is old PHP 4 behaviour, and according to the docs
> is only "supported for compatibility reasons", and personally I think users
> should be encourage to use proper visibility when defining properties.
What’s the benefit here? It seems like a needless backwards-compatibility break. PHP 4
constructors have been proposed to be removed because they cause problems (Filter::filter) and it
simplifies the language. What problems does var cause? Its existence doesn’t seem to hurt anyone -
sure, using public/protected/private is better, but this only matters if you’re reading legacy
code. I’d also be wary of removing it if we’re going to get rid of T_VAR, as that seems like a
useful keyword we might reuse later. So I don’t see why we need to remove this.
It’s also worth noting that removing PHP 4 constructors is unlikely to go ahead. I think Levi is
planning to simply deprecate them instead, since it solves the main problem (Filter::filter broken)
without breaking BC.
Thanks.
--
Andrea Faulds
http://ajf.me/