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

This is only part of a thread. view whole thread
  106584
August 14, 2019 09:09 cschneid@cschneid.com (Christian Schneider)
Am 14.08.2019 um 10:39 schrieb Peter Kokot <peterkokot@gmail.com>:
>> The best counterargument I can give against "cleaning up" is that it takes energy away from actual new features, even if it's just the mental energy of monitoring and responding to long threads like this one. > > Code is like a garden. If there are unwanted weeds and nobody cleans > them up, the flowers don't shine and grow as they should. Cleaning of > the weeds is just as important as new features. A bit less but > important.
Going with your analogy: Some things (like short open tags) are that individual small flower in the corner of the garden which does not multiply. We already spent way too much time discussing it, the rest of the garden needs water and the gardeners are fighting over a dandelion. A bike-shed discussion at its worst: No real gain but everybody has an opinion. Real cleaning up, now that's where it gets interesting. And those discussions tend to be more productive even recently. Oh and: I'm very much afraid the OP was trolling and succeeded in getting people to react, so please, please let this particular thread die :-( - Chris
  106585
August 14, 2019 09:27 peterkokot@gmail.com (Peter Kokot)
On Wed, 14 Aug 2019 at 11:09, Christian Schneider <cschneid@cschneid.com> wrote:
> > Am 14.08.2019 um 10:39 schrieb Peter Kokot <peterkokot@gmail.com>: > >> The best counterargument I can give against "cleaning up" is that it takes energy away from actual new features, even if it's just the mental energy of monitoring and responding to long threads like this one. > > > > Code is like a garden. If there are unwanted weeds and nobody cleans > > them up, the flowers don't shine and grow as they should. Cleaning of > > the weeds is just as important as new features. A bit less but > > important. > > Going with your analogy: Some things (like short open tags) are that individual small flower in the corner of the garden which does not multiply. We already spent way too much time discussing it, the rest of the garden needs water and the gardeners are fighting over a dandelion. A bike-shed discussion at its worst: No real gain but everybody has an opinion. > Real cleaning up, now that's where it gets interesting. And those discussions tend to be more productive even recently. > > Oh and: I'm very much afraid the OP was trolling and succeeded in getting people to react, so please, please let this particular thread die :-( > > - Chris
I'm sorry but until the RFC is still in voting phase, participants should be welcome to express opinions. And the message by OP was correct. PHP is having a lot of these old sins and they are standing out, yes. -- Peter Kokot
  106588
August 14, 2019 09:51 robert@korulczyk.pl (Robert Korulczyk)
W dniu 14.08.2019 o 11:09, Christian Schneider pisze:
> Am 14.08.2019 um 10:39 schrieb Peter Kokot <peterkokot@gmail.com>: >>> The best counterargument I can give against "cleaning up" is that it takes energy away from actual new features, even if it's just the mental energy of monitoring and responding to long threads like this one. >> >> Code is like a garden. If there are unwanted weeds and nobody cleans >> them up, the flowers don't shine and grow as they should. Cleaning of >> the weeds is just as important as new features. A bit less but >> important. > > Going with your analogy: Some things (like short open tags) are that individual small flower in the corner of the garden which does not multiply. We already spent way too much time discussing it, the rest of the garden needs water and the gardeners are fighting over a dandelion. A bike-shed discussion at its worst: No real gain but everybody has an opinion. > Real cleaning up, now that's where it gets interesting. And those discussions tend to be more productive even recently. > > Oh and: I'm very much afraid the OP was trolling and succeeded in getting people to react, so please, please let this particular thread die :-( > > - Chris > >
It is surprising how thing that is considered by one to be a security risk, is treated as nothing relevant by others. This dichotomy is quite disturbing - in what case removing security risk is "no real gain"?
  106590
August 14, 2019 10:09 r@roze.lv ("Reinis Rozitis")
> It is surprising how thing that is considered by one to be a security risk, is treated > as nothing relevant by others. This dichotomy is quite disturbing - in what case > removing security risk is "no real gain"?
It's questionable that a misconfigured environment is a "security" risk caused by language rather than ignorance of the administrator. On that matter you could ask why are all the exec/passthru/proc_open etc functions/features are allowed by default while every other guide on hardening web suggests those to be disabled (added to disable_functions)? I would bet there have been a lot more (actual) security breaches because of unsanitized/unescaped parameters to those. Just to repeat some other people - there are a lot other things to work on than this. rr
  106593
August 14, 2019 10:23 peterkokot@gmail.com (Peter Kokot)
On Wed, 14 Aug 2019, 12:09 Reinis Rozitis, <r@roze.lv> wrote:

> > It is surprising how thing that is considered by one to be a security > risk, is treated > > as nothing relevant by others. This dichotomy is quite disturbing - in > what case > > removing security risk is "no real gain"? > > It's questionable that a misconfigured environment is a "security" risk > caused by language rather than ignorance of the administrator. > > On that matter you could ask why are all the exec/passthru/proc_open etc > functions/features are allowed by default while every other guide on > hardening web suggests those to be disabled (added to disable_functions)? > I would bet there have been a lot more (actual) security breaches because > of unsanitized/unescaped parameters to those. > > Just to repeat some other people - there are a lot other things to work on > than this. > > rr > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
Appologies if these short tags are bumped so many times and cause so much issues but we are at the very starting discussions of PHP 8 also. Major version, where breaking thing was supposed to be possible. So that is one of the reasons why this and similar cleanups are mentioned in the first place. With closing the door to even talk and work on cleanups, or being ashamed of it, or bully others because they want to have a better structure with using PHP 8+, nothing good can come out of it.
> > >
  106598
August 14, 2019 11:01 hisamsonolu@gmail.com (Olumide Samson)
On Wed, Aug 14, 2019, 11:24 AM Peter Kokot <peterkokot@gmail.com> wrote:

> On Wed, 14 Aug 2019, 12:09 Reinis Rozitis, <r@roze.lv> wrote: > > > > It is surprising how thing that is considered by one to be a security > > risk, is treated > > > as nothing relevant by others. This dichotomy is quite disturbing - in > > what case > > > removing security risk is "no real gain"? > > > > It's questionable that a misconfigured environment is a "security" risk > > caused by language rather than ignorance of the administrator. > > > > On that matter you could ask why are all the exec/passthru/proc_open etc > > functions/features are allowed by default while every other guide on > > hardening web suggests those to be disabled (added to disable_functions)? > > I would bet there have been a lot more (actual) security breaches because > > of unsanitized/unescaped parameters to those. > > > > Just to repeat some other people - there are a lot other things to work > on > > than this. > > > > rr > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > Appologies if these short tags are bumped so many times and cause so much > issues but we are at the very starting discussions of PHP 8 also. Major > version, where breaking thing was supposed to be possible. So that is one > of the reasons why this and similar cleanups are mentioned in the first > place. With closing the door to even talk and work on cleanups, or being > ashamed of it, or bully others because they want to have a better structure > with using PHP 8+, nothing good can come out of it. > > > > > > > > I'm with you on this PHP 8 argument.
I think many of this popular languages that's making my PHP professional coding look like kids play make sure their major version shake up many old things, to cleanup old things that's either better not released or would cause some developers to write environment-tied programs. Since we don't have any good cause to leave it be, let it go. Let the user land developers see PHP as a major language they are hoping for. Currently, it's easy to learn, use, break or make. Let them see the intern devs are strict and mature enough to break things when needed and when possible. Break it off if it's not useful or would allow the possibility to write environment tied code(where short tag is not a general idea) and what are we saying? PHP 8 needs major shake up, let's start it from PHP 7 and let the world wow at the internals courage, focus and super ability to implement what's needed. Why wait for a time, when we have little time? Should we wait for cleanups until PHP 9 or PHP 10? Im sure javascript would have moved on around that time as the same language for web, mobile and desktop application, while PHP a major language still keep in doing its stuff at the server side(and the user land get booed as boring programmer who would have to learn multiple languages to get a desktop, mobile and web application designed). Please,clean up.
>
  106602
August 14, 2019 13:31 chasepeeler@gmail.com (Chase Peeler)
On Wed, Aug 14, 2019 at 7:03 AM Olumide Samson <hisamsonolu@gmail.com>
wrote:

> On Wed, Aug 14, 2019, 11:24 AM Peter Kokot <peterkokot@gmail.com> wrote: > > > On Wed, 14 Aug 2019, 12:09 Reinis Rozitis, <r@roze.lv> wrote: > > > > > > It is surprising how thing that is considered by one to be a security > > > risk, is treated > > > > as nothing relevant by others. This dichotomy is quite disturbing - > in > > > what case > > > > removing security risk is "no real gain"? > > > > > > It's questionable that a misconfigured environment is a "security" risk > > > caused by language rather than ignorance of the administrator. > > > > > > On that matter you could ask why are all the exec/passthru/proc_open > etc > > > functions/features are allowed by default while every other guide on > > > hardening web suggests those to be disabled (added to > disable_functions)? > > > I would bet there have been a lot more (actual) security breaches > because > > > of unsanitized/unescaped parameters to those. > > > > > > Just to repeat some other people - there are a lot other things to work > > on > > > than this. > > > > > > rr > > > > > > > > > -- > > > PHP Internals - PHP Runtime Development Mailing List > > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > Appologies if these short tags are bumped so many times and cause so much > > issues but we are at the very starting discussions of PHP 8 also. Major > > version, where breaking thing was supposed to be possible. So that is one > > of the reasons why this and similar cleanups are mentioned in the first > > place. With closing the door to even talk and work on cleanups, or being > > ashamed of it, or bully others because they want to have a better > structure > > with using PHP 8+, nothing good can come out of it. > > > > > > > > > > > > > > I'm with you on this PHP 8 argument. > I think many of this popular languages that's making my PHP professional > coding look like kids play make sure their major version shake up many old > things, to cleanup old things that's either better not released or would > cause some developers to write environment-tied programs. > Since we don't have any good cause to leave it be, let it go. > > Let the user land developers see PHP as a major language they are hoping > for. > > Currently, it's easy to learn, use, break or make. > Let them see the intern devs are strict and mature enough to break things > when needed and when possible. > > Break it off if it's not useful or would allow the possibility to write > environment tied code(where short tag is not a general idea) and what are > we saying? PHP 8 needs major shake up, let's start it from PHP 7 and let > the world wow at the internals courage, focus and super ability to > implement what's needed. Why wait for a time, when we have little time? > Should we wait for cleanups until PHP 9 or PHP 10? > Im sure javascript would have moved on around that time as the same > language for web, mobile and desktop application, while PHP a major > language still keep in doing its stuff at the server side(and the user land > get booed as boring programmer who would have to learn multiple languages > to get a desktop, mobile and web application designed). > > Please,clean up. > > > >
The "shake-ups" that will draw people to PHP are the new features, the majority of which don't require BC breaks and were listed earlier in this thread. Go find a group of anti-PHP developers. Tell them how wonderful PHP 9 is going to be. When they ask why, tell them "We've got rid of short tags!" and see how they react. Now, find another group of anti-PHP developers. Tell them how wonderful PHP 9 is going to be. Tell them it will have generics, enums, union types, and JIT. Also mention that short tags will still be allowed. See how they react. They might not really care, and still not like PHP, but I can guarantee you it won't be because short tags still exist. -- Chase Peeler chasepeeler@gmail.com
  106596
August 14, 2019 10:34 robert@korulczyk.pl (Robert Korulczyk)
W dniu 14.08.2019 o 12:09, Reinis Rozitis pisze:
> It's questionable that a misconfigured environment is a "security" risk caused by language rather than ignorance of the administrator.
This is not about misconfigured environment. This is about accidental usage of *language* feature, which *by design* can lead to code leaks (so application bug, not misconfigured environment). Clearly not a language problem that it has dedicated feature to shoot yourself in the foot...
> On that matter you could ask why are all the exec/passthru/proc_open etc functions/features are allowed by default while every other guide on hardening web suggests those to be disabled (added to disable_functions)?
These methods have their purpose (pretty important BTW), short open tags is just "don't use it!!!" feature. Regards, Robert Korulczyk
  106597
August 14, 2019 10:48 r@roze.lv ("Reinis Rozitis")
> This is about accidental usage of *language* feature, which *by design* can lead to code leaks (so application bug, not misconfigured environment). Clearly not a language problem that it has dedicated feature to shoot yourself in the foot... > > These methods have their purpose (pretty important BTW), short open tags is > just "don't use it!!!" feature.
Sure those are important - I was just pointing out that the "security card" is questionable since the language has more dangerous features which ask for the user to be careful and responsible about them rather than making everything foolproof and accident-free. Also it's not by design - the only way code can leak is when it has been using '
  106599
August 14, 2019 11:30 robert@korulczyk.pl (Robert Korulczyk)
> Sure those are important - I was just pointing out that the "security card" is questionable since the language has more dangerous features > which ask for the user to be careful and responsible about them rather than making everything foolproof and accident-free.
Honestly, I don't see how allowing exec/passthru/proc_open is a security risk. These are just tools. We're talking about programming language - if you're running PHP script as user X you should expect that it could do anything that user X can do. If you don't trust this script, just don't run it - disabling exec/passthru/proc_open does not change much since PHP is powerful enough to hurt you badly without executing any shell commands. If you think that disabling exec function will protect you from malicious scripts, then you have real security problem related directly to your environment and completely unrelated to PHP (it is OS responsibility to disallow access to part of the system, which should not be accessed by a particular program).
> Considering the current RFCs has it really been decided as "don't use it" (when/where?)?
https://www.php.net/manual/en/language.basic-syntax.phptags.php "PHP also allows for short open tag
  106600
August 14, 2019 12:14 r@roze.lv ("Reinis Rozitis")
> Honestly, I don't see how allowing exec/passthru/proc_open is a security risk. > These are just tools. We're talking about programming language - if you're > running PHP script as user X you should expect that it could do anything that user > X can do. If you don't trust this script, just don't run it
Depends on how you look at if exec($_GET['param']) is a language responsibility or programmers? On the same level you can then expect that programmer X always uses '> https://www.php.net/manual/en/language.basic-syntax.phptags.php > > "PHP also allows for short open tag available if enabled using the short_open_tag php.ini configuration file directive, > or if PHP was configured with the --enable-short-tags option)."
Which is actually the other way around - enabled by default / disabled if configured via ini. It feels most people who argue about the feature (are not in the burn it with fire and everyone who uses them should just go away) would be fine (enough) if it aligned to what's written in the documentation and then make deliberate decision to enable those. rr
  106601
August 14, 2019 13:19 robert@korulczyk.pl (Robert Korulczyk)
W dniu 14.08.2019 o 14:14, Reinis Rozitis pisze:
> Depends on how you look at if exec($_GET['param']) is a language responsibility or programmers?
Please, let's keep this discussion at some level of sanity... You basically need stick to static HTML if you're considering possibility of such exec() usage as a security issue. They're at least 3 main deferences between short open tags and exec-like functions: 1. exec-like functions have their purpose without any straight-forward alternative, while `` is intended usage of short open tags. 3. Because of point 2, there is no IDE or editor which will generate code like `exec($_GET['param'])`, while there is at least one popular IDE which will generate code with short open tags. Regards, Robert Korulczyk
  106603
August 14, 2019 13:50 r@roze.lv ("Reinis Rozitis")
> Please, let's keep this discussion at some level of sanity... You basically need > stick to static HTML if you're considering possibility of such exec() usage as a > security issue.
This discussion has gone out of sanity levels the moment people started to state that short tags is one (of the many) things PHP has why new programmers and companies don't pick the language or why colleagues laugh at you and is a blocker of new bright future etc. and now in this moment this is a do or die situation otherways next year everyone will be writing in javascript.
> 1. exec-like functions have their purpose without any straight-forward alternative, while ` Except there are 4-5 functions which do the same not to mention `` backtick syntax (can't there be an accident mixing those with single quotes?).
> `` is intended usage of short open tags.
On this I could also say that recommendations are to store all credentials outside webroot, but again it also qualify as something different than by accident generated code in IDE, just to show that the "security issue" can be stretched however you like.
> You basically need stick to static HTML
Maybe. But let's end at this .. rr
  106604
August 14, 2019 14:49 robert@korulczyk.pl (Robert Korulczyk)
> This discussion has gone out of sanity levels the moment people started to state that short tags is one (of the many) > things PHP has why new programmers and companies don't pick the language or why colleagues laugh at you and is a > blocker of new bright future etc. and now in this moment this is a do or die situation otherways next year everyone > will be writing in javascript.
No one said that (except you). But current reaction for this RFC could be depressing. I'm using PHP for quite a long time and I really hoped that someday we'll be able to get rid of all (or at least the most of them) the traps and annoying little things from the old days. That doesn't sound realistic anymore...
> Except there are 4-5 functions which do the same not to mention `` backtick syntax (can't there be an accident mixing those with single quotes?).
I was talking about all these functions that allows to execute shell commands. What is the point of disabling only one of them? I thought that the problem is in functionality, not in the name :P
>> `` is intended usage of short open tags. > > On this I could also say that recommendations are to store all credentials outside webroot,
I'm afraid you don't understand the problem. Having such code outside of webroot does not help you much if this file will be included from another file (which uses `
  106607
August 14, 2019 15:37 chasepeeler@gmail.com (Chase Peeler)
On Wed, Aug 14, 2019 at 10:49 AM Robert Korulczyk <robert@korulczyk.pl>
wrote:

> > This discussion has gone out of sanity levels the moment people started > to state that short tags is one (of the many) > > things PHP has why new programmers and companies don't pick the language > or why colleagues laugh at you and is a > > blocker of new bright future etc. and now in this moment this is a do or > die situation otherways next year everyone > > will be writing in javascript. > > No one said that (except you). > > 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.
> But current reaction for this RFC could be depressing. I'm using PHP for > quite a long time and I really hoped that someday we'll be able to get rid > of > all (or at least the most of them) the traps and annoying little things > from the old days. That doesn't sound realistic anymore... > > This is exactly what we're talking about. You act as if leaving short tags in PHP means nothing will ever get cleaned up. That there is absolutely no
reason at all we might want to consider leaving them, so, the fact that we are is just a signal that no one is willing to entertain the idea of BC breaks for anything ever.
> > > Except there are 4-5 functions which do the same not to mention `` > backtick syntax (can't there be an accident mixing those with single > quotes?). > > I was talking about all these functions that allows to execute shell > commands. What is the point of disabling only one of them? I thought that > the > problem is in functionality, not in the name :P > > Or, maybe, it's just that the negative consequences of removing those functions doesn't justify the positives that would be gained? That's the
whole argument with short tags. It's not "Short tags are wonderful!" or "There is absolutely NOTHING bad about short tags and how they are currently handled." We've just been saying that while there are negatives, they are negatives that have existed for 20 years without causing large scale issues. The issues they cause do not justify removing them and the impact it will have on existing developers and code bases. It causes a large amount of difficulty for many people to upgrade while only solving a possible security issue that is actually pretty easy to avoid. Honestly, while I didn't have a vote, if the RFC didn't include language about actually removing short tag support in PHP 9, I would have encouraged people to support it. I have no issues with helping push people towards not using short tags, and then at some point in the future discussing whether to remove support or not. In the end, what I see is one side (those for keeping short tag support) readily admitting that there are issues with short tags, but they aren't outweighed by the negatives. I see the other side (those for removing short tag support) acting as if there were absolutely no negatives at all to removing them. You even said exactly that: "Since we don't have any good cause to leave it be, let it go." They also inflate the issues with short tags to hyperbolic levels, making them into a huge security implication, the driving force behind anti-PHP sentiment, and the barrier to new developers picking up the language. That makes it impossible to have a reasoned discussion on the argument. It's like one side is saying "I know fire is dangerous, but I think it's a good idea to have some matches handy just in case." And the other side saying "No, if we have matches no one will ever come to our house and all of our neighbors will laugh at us and we'll almost definitely burn the house down." Even though you've had matches in the house for the last 20 years without any issues.
> >> `` is intended usage of short open tags. > > > > On this I could also say that recommendations are to store all > credentials outside webroot, > > > I'm afraid you don't understand the problem. Having such code outside of > webroot does not help you much if this file will be included from another > file (which uses ` password is just the simplest example - single non-working `if` can lead to > a > wide range of bugs with serious consequences, far beyond code leak. > > What about the display_errors ini directive? That seems like a security risk as well, since error messages can contain sensitive information. I
know keeping/removing it isn't mutually exclusive with keeping/removing short tags. I'm just curious why it's never mentioned by anyone that suddenly is so concerned about the security implications of short tags.
> > > Regards, > Robert Korulczyk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Chase Peeler chasepeeler@gmail.com
  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