> Good for you! Come take a stab at my legacy project. It's horrendous. We have > some files where using PhpStorm's automatic formatting actually caused > stuff to break. So, you can see why I might be a little reticent to depend on > an automated tool to change my php tags. I'll let you start with a 12k+ > line file of spaghetti code. This file contains a lot of functions (not OO) > used across the legacy parts of the application. As such, it's included at > the top of pretty much every PHP page. So, make sure you don't leave a typo, > because it'll break the entire application!
I know how painful could be maintaining legacy code, but did you tried to run php-cs-fixer against this 12k+ file with PHP-spaghetti and report some actual issues? You're spending time theorizing how automated tool can break your legacy code, but it would be far more productive if you spend it on actual tests - this would give us very valuable insights how serious this problem is. Right now these are nothing more than *speculations* based on usage of *completely different tool* for *completely different task*. Please, don't treat it as some hard argument. > While you are at it, you can explain to my executive team (I don't work for a > software company) why it's worth putting in the time to modify all > these "don't touch unless it's an emergency" legacy files to upgrade PHP when > the current version seems to be working fine from their perspective. Sure. It would be something like: "Hey, it's *emergency*!" ;) > That's another difference I've seen from the two sides of the argument. Those > in favor of removing them usually say things like "It doesn't seem like > a big deal to me" or "I converted a project and it was really easy" or > "People shouldn't be using short tags anyway, so who cares." While those > against removing them usually say things like "I can see how this could be a > huge problem for a large number of users" or "This could definitely block > a lot of people from upgrading in a timely manner." This is one side of the coin. I'll show you another: I gave a real-world example that short open tag could lead to serious fuckup and be undetected for quite a long time. I also gave an example of how easy is to accidentally introduce short open tags in your code. There are other people who also treats short open tags as dangerous feature and security issue. Despite this, I can read multiple times that "short open tags are no-issue" or "there is no gain in removing short open tags". In counterargument for this RFC you can read that "Deprecating short tags, as illustrated in this counterargument, brings us *virtually no value at all*.". There is no difference between both "camps" - both are focusing on their perspective and their arguments, while underestimating problems and arguments of other "camp". For you existence of short open tags is minor issue, for me migrating to `<?php` is simple and straight-forward change, far simpler than other BC breaks in the past (I recently migrated quite big application to PHP 7.2 - replacing `<?`, even without existing tools, looks like a walk in the park now :P). Regards, Robert Korulczyk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
