Re: [RFC] [VOTE] Deprecate PHP's short open tags

From: Date: Wed, 24 Apr 2019 15:27:39 +0000
Subject: Re: [RFC] [VOTE] Deprecate PHP's short open tags
References: 1 2 3 4 5 6 7 8 9 10 11 12  Groups: php.internals 
Request: Send a blank email to internals+get-105381@lists.php.net to get a copy of this message
> On 24 Apr 2019, at 22:16, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > On Wed, Apr 24, 2019 at 11:02 AM Stephen Reay <php-lists@koalephant.com > <mailto:php-lists@koalephant.com>> wrote: > > > On 24 Apr 2019, at 21:35, Chase Peeler <chasepeeler@gmail.com > > <mailto:chasepeeler@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. > > 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. > > 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. > 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 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 > chasepeeler@gmail.com <mailto:chasepeeler@gmail.com>

« previous php.internals (#105381) next »