Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91488
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 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>
 <56D86C00.6000904@fleshgrinder.com>
Message-ID: <56D870FC.80205@gmail.com>
Date: Thu, 3 Mar 2016 17:14:36 +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: <56D86C00.6000904@fleshgrinder.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)

Fleshgrinder wrote on 03/03/2016 16:53:
> The fact that
> there are no plans regarding the old syntax and thus keeping the
> duplication indefinitely is the actual problem.

Having no plans to use something doesn't make it a problem. There still 
needs to be some actual problem you are solving by removing it.


>> 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.
> It seems as if this is not the issue for the people who are against
> removing the "var" keyword from PHP 8. They simply do not want to change
> their scripts at all. The described procedure is truly time consuming
> since it involves to check all usages everywhere as well. Simply
> changing from "var" or "public" to any other visibility is a brutal change.

Let's not make generalisations about people's motives here. I am 
expressing *my* reasoning for being against removal; others may have 
other reasons, and you can discuss those with them.

My point was that bulk changing "var" to "public" is a 
counter-productive change. It removes the information "this property's 
visibility has not been reviewed", without actually adding any value.

This leaves us with a small gain (clearer to new users that the correct 
keyword is "public"), and two small costs (the need to run a script over 
all existing code to change "var" to "public", and the loss of 
opportunity to manually review all instances of "var"); I'm not willing 
to quantify those, but the balance doesn't feel in favour of change to me.

If there were some way of preventing users writing var in *new* code, I 
would be all for it - there is no advantage to doing so, and it adds no 
value to have two ways of writing "public". But there is no way for the 
engine to distinguish new code from "legacy" code which already contains 
the keyword. If someone can come up with a clean mechanism for doing 
that (and in particular, for new code to say "I'm including this legacy 
library which I will replace with modern code shortly, don't bother 
telling me how many deprecated features it uses"), then I would be very 
interested.

Regards,
-- 
Rowan Collins
[IMSoP]