On Wed, Aug 14, 2019 at 12:22 PM Robert Korulczyk <rob...@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 `<?` to `<?php` using > 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 chasepee...@gmail.com
