Re: [PHP-DEV] Deprecate PHP's short open tags, again

This is only part of a thread. view whole thread
  106611
August 14, 2019 16:22 robert@korulczyk.pl (Robert Korulczyk)
> While possibly a bit hyperbolic, most of the arguments basically come off that way to me as well. I've definitely viewed most of what you've said in > that manner.
I guess we're in some kind of limbo where half of the people do not consider problems which short open tags create as serious, and other half does not consider BC break implications as serious. I already migrated some quite big legacy apps from `
  106612
August 14, 2019 17:00 chasepeeler@gmail.com (Chase Peeler)
On Wed, Aug 14, 2019 at 12:22 PM Robert Korulczyk <robert@korulczyk.pl>
wrote:

> > While possibly a bit hyperbolic, most of the arguments basically come > off that way to me as well. I've definitely viewed most of what you've said > in > > that manner. > > I guess we're in some kind of limbo where half of the people do not > consider problems which short open tags create as serious, and other half > does not > consider BC break implications as serious. > No, we're not. Only people that are in favor of removing short tags seem to
be making this RFC a referendum on BC breaks in general. We understand there is a security risk. As others have pointed out, it's a rather minor one. Code gets deployed with short tags onto a server that has short tag support turned off. The solution is to turn short tags back on. It's a setting that can be turned on/off at any level, so, just throw it in your ..htaccess file. If you use windows and IIS like me, you can set it in your registry. Not ideal, but, it works. If there was no way to quickly enable short tag support, the discussion might be different. Since there is, the security implications, while they exist, are mitigated. It's further mitigated by the fact that almost everyone writing portable code is not using short tags to begin with. This means the odds of me downloading a 3rd party library that uses short tags is pretty slim. If I actually do some due diligence (look at the source code, stick to something actively maintained, something with good reviews, etc) it's even slimmer. If it's code I'm writing myself, then, I should no better than to write code with short tags if I'm going to deploy it to a server that doesn't support them (or that I don't have control over). As Zeev has mentioned many times, in retrospect, short tags probably should have never been supported. If they never had been supported, then there wouldn't be any case for adding support for them now. That doesn't change the fact that they have been support for 20 years, and removing support for them now has huge implications for a lot of non-portable legacy code.That is compared with a security issue, that while it does exist, is very unlikely to occur for anyone using a modicum of common sense, and can easily be resolved if it does.
> I already migrated some quite big legacy apps from ` existing tools for this, and I can't even image simpler BC break to deal > with. So for me "it will be so hard to upgrade" arguments are also > exaggerated, and that's why I'm concerned about future BC breaks - if such > simple > change encounters such fierce resistance, then what kind of BC break can > be accepted? > > 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! 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. 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." I'm one of the few people I've seen that is against removing short tags AND has provided examples in their own code bases of how it will impact them in a negative way. Most of those against it have based their opinion on knowing that others will be negatively impacted by this, even if they personally won't. Honestly, if it was just my code that was the concern, I wouldn't be as vocal. I can suck it up and fix things. I can cut through the red tape and get it done at some point so we can upgrade. I'm vocal on this because I know there are other developers out there dealing with a legacy code base like mine, if not worse, that might not be able to just bite the bullet and get it done.
> Regards, > Robert Korulczyk >
-- Chase Peeler chasepeeler@gmail.com
  106616
August 14, 2019 19:56 robert@korulczyk.pl (Robert Korulczyk)
> 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 `
  106613
August 14, 2019 17:01 hisamsonolu@gmail.com (Olumide Samson)
On Wed, Aug 14, 2019, 5:23 PM Robert Korulczyk <robert@korulczyk.pl> wrote:

> > While possibly a bit hyperbolic, most of the arguments basically come > off that way to me as well. I've definitely viewed most of what you've said > in > > that manner. > > I guess we're in some kind of limbo where half of the people do not > consider problems which short open tags create as serious, and other half > does not > consider BC break implications as serious. > I already migrated some quite big legacy apps from ` existing tools for this, and I can't even image simpler BC break to deal > with.
So for me "it will be so hard to upgrade" arguments are also exaggerated,
> and that's why I'm concerned about future BC breaks - if such simple > change encounters such fierce resistance, then what kind of BC break can > be accepted? > This was exactly my reason for participating in this discussion, if such
simple BC break encounters fierce and lengthy-weighted resistance, I'm not sure there will ever be a BC break, only additions without a necessary cleanup. That's just like, there's a precedent to resist all kinds of BC break simply because there's no positive impact on the change. Millions of code can be migrated through many existing libraries in short time frame to comply with the short tag depreciation. I think the resistance is actually the reason this discussion(thread) gets this lengthy. At the end of all, we either have it or leave it. Happy coding.
> > Regards, > Robert Korulczyk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  106615
August 14, 2019 18:19 claude.pache@gmail.com (Claude Pache)
> Le 14 août 2019 à 19:01, Olumide Samson <hisamsonolu@gmail.com> a écrit : > > This was exactly my reason for participating in this discussion, if such > simple BC break encounters fierce and lengthy-weighted resistance, I'm not > sure there will ever be a BC break, only additions without a necessary > cleanup. > > That's just like, there's a precedent to resist all kinds of BC break > simply because there's no positive impact on the change.
No, BC breaks and cleanups have been regularly implemented in the past, and that will continue. Two recent examples among several others: https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase <https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase> https://wiki.php.net/rfc/ternary_associativity <https://wiki.php.net/rfc/ternary_associativity> About short-open tags. Many people thought that this particular BC break or cleanup was not useful enough. That’s all. —Claude