On Wed, Apr 24, 2019 at 12:04 PM Peter Bowyer <rey...@php.net> wrote:
> Surely the time for vocal opposition was _before_ voting closed? > > And I raised my opposition multiple times. That included one email where I laid out a case for why each reason listed for the RFC did not justify the major BC break. No one ever responded to even one of those points. > Peter > > On Wed, 24 Apr 2019 at 16:51, Chase Peeler <chasepee...@gmail.com> wrote: > >> 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 >> > -- Chase Peeler chasepee...@gmail.com
