Hi all, On Thu, Feb 12, 2015 at 8:57 PM, Andrea Faulds <a...@ajf.me> wrote:
> > 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. 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 yohg...@ohgaki.net
