Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91498 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 12362 invoked from network); 4 Mar 2016 11:38:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Mar 2016 11:38:31 -0000 Authentication-Results: pb1.pair.com header.from=rowan.collins@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=rowan.collins@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender) X-PHP-List-Original-Sender: rowan.collins@gmail.com X-Host-Fingerprint: 74.125.82.41 mail-wm0-f41.google.com Received: from [74.125.82.41] ([74.125.82.41:37643] helo=mail-wm0-f41.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 88/7D-08749-6B379D65 for ; Fri, 04 Mar 2016 06:38:30 -0500 Received: by mail-wm0-f41.google.com with SMTP id p65so25991680wmp.0 for ; Fri, 04 Mar 2016 03:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=FgML/IVeVWwA+bJ8V0qbjHDPxXKdcXA6D8KeXc0GzYg=; b=L8fzErwwz/mX4lX/W5MxkS5aF8gFDjDbJPFzdg+LqQA4MPaCSYlUNHA95rACmxDaDD qDmz6Z0iZE5GK1Rf6bDtfNGlGF6RHHuVZeHJrrdGIi+z+gWCrx8X48rMFX1QH8yw7vwW j9KhSsUFsa6fl0VpAZoKw7Uu5/vG7M7Wc8XOrSEn3BE2bN/5t5MzbisP2T1s8arYUzSB eokn0bLWTWoyWC21wMxT70rNcGBG+W5oPN8RBxIjNf7ixZkuxMxIgP8ajfr9irR5OvMs HKthpq4bzRWyS3W/aMkNvAYJiyuhgUAE4Z046Y4lpFm5qasVTrJntdxPVXZlp6quHwOT 48Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=FgML/IVeVWwA+bJ8V0qbjHDPxXKdcXA6D8KeXc0GzYg=; b=Z2joxPp7tl6IxhKnCoR2lATTi3kVKLIg2yOV9EKukav8CpjOn5W8XzAO8vCr2bVtC2 QYr9Q36PQoH/ENYG1Mo2PcomrFTvn5ZfZTD8MAvBuQ01h3k/ZNeS8XDK+X12nnq2edRZ 2h355mPgStJTFU/EV498ZQZ4F68b8eda+FPKImNFJmZIazMsTDwrQtE909fTu98NB2hT Z4JeUcq4/VZzwvEKH2ePSL9/rkiGgK2HaPYTPHSMOaoeSuwFjnQuVKYkU1bRB2deVaaW eMB0aIpQZ1h0eu/KM1Vl3HBsiLJY2mFg9+UPCW1YZKe+MVcqxjJLc40yV9LD8AdYCeYf fkAQ== X-Gm-Message-State: AD7BkJKT8Qm3MRB+8IpSrxHkxiOpvFXPmeZUcAhqviM4mT3OPtIJ7rR1Kd5W5yIQS2IIQg== X-Received: by 10.194.83.42 with SMTP id n10mr8720661wjy.20.1457091507746; Fri, 04 Mar 2016 03:38:27 -0800 (PST) Received: from [192.168.0.141] ([93.188.182.58]) by smtp.googlemail.com with ESMTPSA id jo6sm2900727wjb.48.2016.03.04.03.38.26 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Mar 2016 03:38:26 -0800 (PST) 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> <56D96F4F.9020306@lsces.co.uk> Message-ID: <56D97352.30500@gmail.com> Date: Fri, 4 Mar 2016 11:36:50 +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: <56D96F4F.9020306@lsces.co.uk> 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) Lester Caine wrote on 04/03/2016 11:19: > 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'm not sure I follow. What do you mean by "comment 'var' entries"? To my knowledge, /** @var ... */ is the correct notation for PHPDoc for a property, whatever its visibility, but maybe you're talking about some other comments? > 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? This much I agree with. I see no urgency to batch update, even if the cost of doing so is low. Regards, -- Rowan Collins [IMSoP]