Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Deprecate properties using var »

[RFC] Deprecate properties using var

php.internals

Pierre du Plessis

11 years ago
Hi all 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. [0] https://wiki.php.net/rfc/remove_php4_constructors Regards Pierre du Plessis

Andrew Faulds

11 years ago
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/

Yasuo Ohgaki

11 years ago
Hi all, On Thu, Feb 12, 2015 at 8:57 PM, Andrea Faulds <ajf@ajf.me> wrote:
> > 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.
I thought I filed this as Trait bug, but there isn't. I might forgot to report it. http://3v4l.org/pL3Hr Class calls trait function that is PHP4 constructor. This could be resolved by removing PHP4 constructor. Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Matteo Beccati

11 years ago
On 13/02/2015 09:27, Yasuo Ohgaki wrote:
> I thought I filed this as Trait bug, but there isn't. I might forgot to > report it. > > http://3v4l.org/pL3Hr > > Class calls trait function that is PHP4 constructor. > This could be resolved by removing PHP4 constructor.
what does this have to do with using "var"? Cheers
-- Matteo Beccati Development & Consulting - http://www.beccati.com/

Yasuo Ohgaki

11 years ago
On Fri, Feb 13, 2015 at 6:09 PM, Matteo Beccati <php@beccati.com> wrote:
> what does this have to do with using "var"?
Sorry. I posted to wrong thread. Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Stas Malyshev

11 years ago
Hi!
> 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
How the life of the PHP user would be improved by this? Except for making more code break, I'm not sure how it's helpful, could you explain?
> 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.
"var" is the same as "public", public is proper visibility.
-- Stas Malyshev smalyshev@gmail.com