Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91480
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
To: internals@lists.php.net
References: <1F.91.55238.41F10D65@pb1.pair.com>
 <CAHvhOfhYpnjkSjuo09TY7irhgW5UxNYZcWqtAr0iCcUAqJUgqw@mail.gmail.com>
 <CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com>
 <FA.10.10408.29514D65@pb1.pair.com> <56D42CD3.6020602@gmail.com>
 <DB.E1.07778.3D165D65@pb1.pair.com> <56D57DF4.8000906@gmail.com>
 <56D5D2AD.6070805@gmail.com> <56D5DDA6.4080607@fleshgrinder.com>
 <40.73.36499.548B6D65@pb1.pair.com> <56D6BBD0.5010505@gmail.com>
 <56D73386.3000903@fleshgrinder.com> <86.68.21983.A2508D65@pb1.pair.com>
 <56D80C33.2070102@lsces.co.uk>
 <CAJaRsPvNJVrh_jKZrnwitJ9DSRLa=1297G7onwD41MBGRUGbzg@mail.gmail.com>
Message-ID: <56D83678.1090006@gmail.com>
Date: Thu, 3 Mar 2016 13:04:56 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CAJaRsPvNJVrh_jKZrnwitJ9DSRLa=1297G7onwD41MBGRUGbzg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
From: rowan.collins@gmail.com (Rowan Collins)

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]