Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91497 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 9583 invoked from network); 4 Mar 2016 11:19:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Mar 2016 11:19:48 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:47384] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5B/FC-08749-25F69D65 for ; Fri, 04 Mar 2016 06:19:47 -0500 Received: (qmail 24289 invoked by uid 89); 4 Mar 2016 11:19:43 -0000 Received: by simscan 1.3.1 ppid: 24280, pid: 24286, t: 0.0745s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.155.186.161) by mail4.serversure.net with ESMTPA; 4 Mar 2016 11:19:43 -0000 To: internals@lists.php.net References: <1F.91.55238.41F10D65@pb1.pair.com> <56D42CD3.6020602@gmail.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> <56D83678.1090006@gmail.com> <56D839B9.4090502@lsces.co.uk> <56D83AFA.3040509@gmail.com> Message-ID: <56D96F4F.9020306@lsces.co.uk> Date: Fri, 4 Mar 2016 11:19:43 +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: <56D83AFA.3040509@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:24, Rowan Collins wrote: >> 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. > > The script that Colin linked > (https://gist.github.com/colinodell/5fb5e5d474674f294a38) uses an > in-language tokenizer, not just text find-and-replace, so this is a > solved problem. If this turns out to not be smart enough, one built on > top of Nikita's PHP-Parser project would be pretty easy as well: > https://github.com/nikic/PHP-Parser/ My main reason for not taking that brute force approach is actually the same. Many of the comment 'var' entries relate to the use of the identified var. So changing one without the other just creates more problems? It's the documentation style from 15 years ago that is just as important to maintain and something that is not on the current roadmap? The whole process needs addressing not just one element. I've no problem that as code is tidied these elements get replaced and that is already part of my own process. It's simply a matter of just how 'essential' it is that this is done, and I don't see any pressing need as yet to remove var? -- 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