On Wed, Apr 24, 2019 at 11:27 AM Stephen Reay <php-li...@koalephant.com> wrote:
> > > On 24 Apr 2019, at 22:16, Chase Peeler <chasepee...@gmail.com> wrote: > > > > > > > > On Wed, Apr 24, 2019 at 11:02 AM Stephen Reay <php-li...@koalephant.com > <mailto:php-li...@koalephant.com>> wrote: > > > > > On 24 Apr 2019, at 21:35, Chase Peeler <chasepee...@gmail.com <mailto: > chasepee...@gmail.com>> wrote: > > > > > > If I get started now, maybe I can have everything fixed by the time > 8.1 is > > > released. > > > > > > Two characters less than this sentence of yours is a 1-liner find/sed > script to replace all `<? ` with `<?php `. > > Would you really feel confident doing a blind find/replace on 6,000+ > instances? > > It’s hardly “blind”. This is what version control is for. You make a > change, and then either view the diff locally, and/or commit/push it, and > ask others to help review the diff. > > I literally just ran the script referenced above on a client project, > eyeballed the diff, and committed the changes it made to a branch. Once I’m > not in the middle of anything I’ll review it again and then merge it. > > How big of a project? How many changes? You really think 6,787 changes among 1,656 files can just be eyeballed? > > > > what about <?if ... `<? ` wouldn't match that. I have instances of that > in my code, though. > > So change the pattern to replace `<?` followed by anything except an > equals sign. > > <?if => <?phpif wouldn't work. It would have to be <? that is not part of string (inside quotes, heredoc, etc). Even that could be a legitimate case, though, if something is using eval, god forbid. '<? ' can be a straight replacement with '<?php' but anything else '<?(?!php)' gets replaced with '<?php ' > > > > What if I utilize a 3rd party library that, while no longer support, > works fine, but is now broken for no other reason than the fact that <? is > no longer supported? Whether I should be using that library or not is > irrelevant. The fact is, I am, and the fact that I won't be able to use it > in 8.0 is a barrier to me upgrading. > > > > You do the same thing as if the library had a security issue or some other > bug. If it’s unsupported, you have to support it, or you have to find a > replacement. It’s not like you’re dealing with a compiled module that you > can’t edit. Run the same fix for short tags on the library. > > All valid options. Doesn't change the fact that it's more code to update meaning more time required to prepare for the upgrade. > > I don't trust mass find/replace tools like php-cs-fixer. Some of our > legacy code is really ugly. Auto-formatting with PhpStorm will break it. I > don't mind using an interactive tool, but that means I have to sit there > and hit Y or N for 6,787 instances. Some of them will probably require me > to actually open the file up and check out the surrounding context as well. > And, what happens if I miss one? I run the risk of code leak. > > If auto formatting ‘breaks’ your code, you have a bigger problem than > short tags. > > I never said that our code was good. Most of our legacy code isn't ever touched. It's a mess of 10k+ line spaghetti files. It works, and until we are able to replace it, we just leave it alone. Now we are forced to go in there and mess with it for something that doesn't even pertain to the functionality of our application. Also, you didn't address the issue of missed instances. There is no way to be 100% sure any automated or manual process of replacing the tags will get everything. One of the justifications for this RFC was the possibility of code leak if code with short tags is loaded in an environment that has short tags disabled. We've decided to fix that by making sure that any code with short tags will DEFINITELY leak code. That makes a lot of sense. Eyeballing a diff isn't going to help you find missed instances either. > > > > I think it's great that many of you have code bases that are in pretty > good shape and this change isn't going to have much of an impact on you. > That's not my case, though. It's not the case for a LOT of people. I'm not > against BC breaks - even major ones - if they are justified. I have yet to > see any good justifications for such a massive BC break. > > > > The fact is that this change WILL prevent a lot of people from being > able to upgrade to 8.0 in a timely manner. Anyone that has to justify > spending time to prepare for an upgrade to people that don't understand the > benefits of the upgrade will have an ever harder time trying to justify the > extra time necessary. I also think you are going to find a good number of > people that will upgrade (or use PHP for the first time) unaware of the > change. They'll attempt to load older code that has short tags in it. It > won't work. They'll say "screw it" and use python or node. > > -- > > Chase Peeler > > chasepee...@gmail.com <mailto:chasepee...@gmail.com> > > It's not that I'm against the idea of abolishing short tags. It's that I don't feel the problems abolishing them will cause are justified by the reasons given for abolishing them. No matter how easy you think it is to deal with this, it won't change the fact that it's going to be a barrier to upgrading for a lot of people. It's going to have a negative impact on 8.0 adoption. It's going to lead to a larger number of people running PHP versions that have reached EOL. In the end, it's going to hurt the market share and reputation of PHP. -- Chase Peeler chasepee...@gmail.com
