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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
