Hi Pierre, > On 12 Feb 2015, at 11:51, Pierre du Plessis <pie...@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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
