Re: [RFC] [VOTE] Deprecate PHP's short open tags
| From: | Stephen Reay | 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>