Colin O'Dell wrote on 03/03/2016 12:47:
If you're staying on PHP 5.x or 7.0, no changes would be needed. If you're upgrading to 7.1+, you would need to either hide deprecation notices or take 30 seconds to run that script.
This isn't quite true. At the moment, PHP has no mechanism for hiding notices within particular libraries, so if you're using a third-party library, you have to either persuade the maintainer to put out a new release, or maintain a fork, either of which may require significant effort.
My understanding is that 'var' is simply an alias for 'public' so they should behave identically. Could you please provide an example where 'var' is not replaceable by 'public'?
I'm not sure what Lester had in mind, but in many cases legacy code which used "var" should actually be updated to mark properties as "protected" or "private" instead. Such properties are public only because PHP4 had no other visibility, and explicitly marking them all as "public" simply masks the real job, which is assessing which visibility each property should have.
It occurs to me that if I saw "var", I would not think "that should be public", but "that needs assessing for visibility". I do the same with legacy code where methods are written as "function foo()" rather than "public function foo()" - I check whether it should actually be public, and also in that case whether it should be static.
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
