Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91481
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
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>
 <56D83678.1090006@gmail.com>
Message-ID: <56D839B9.4090502@lsces.co.uk>
Date: Thu, 3 Mar 2016 13:18:49 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <56D83678.1090006@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
From: lester@lsces.co.uk (Lester Caine)

On 03/03/16 13:04, Rowan Collins wrote:
> 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.

Additionally we ARE still having to maintain older versions of these
same libraries ...

>> 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.

Actually my problem is even more simple than that - although it may be
possible to further filter the lookup for 'var ' ( note the space ) many
of the results are simply not text that needs changing. Many previous
changes have been possible simply with a global replaceand pick up the
odd mistake. var is simply not a candidate for that so while many
results can simply be skipped, each has to be reviewed and at that point
one may want to use something other than just public.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk