On 3/3/2016 6:14 PM, Rowan Collins wrote: > 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.
I think in general that it would be helpful to have clear guidelines regarding such topics. They would make deprecation discussions in general simpler. On 3/3/2016 6:14 PM, Rowan Collins wrote: > 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. I understood your motivation and it is a very valid as well as honorable one. > 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. I always thought that E_STRICT is exactly that. I mean, an upgrade path like ... # do nothing in PHP 5 (as is), # emit E_STRICT in PHP 7, # emit E_DEPRECATED in PHP 8, # remove in PHP 9 ... would be fine with me too and go back to what I said initially: a clear policy. Note that it would add several more years to the upgrade path (6 years?). Of course it is bad that people simply suppress those errors but that is something that is completely out of control for us. People could easily log them into a separate log as well during development and disable them in production ... Such a practice could also be easily applied to the RFC that proposes to clean up many old inconsistent functions ... # do nothing in PHP 7, # emit E_STRICT in PHP 8, # emit E_DEPRECATED in PHP 9, # remove in PHP 10. That results in around 9 years of time to adopt. https://wiki.php.net/rfc/consistent_function_names The biggest problem is when languages change to fast and for no real benefit as we have seen it with many other languages and it almost happened with PHP 6 (although the intention was good there). -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
