Hi there! Perhaps I missed and someone already suggested, but didn't consider a compromise option: just change the default value short_open_tag=false, and DON'T removes the option from php.ini?
If someone uses short tags - ok, they will change the default value to true and everything will be as before, who won't change it - will enjoy the full syntax — Sincerely, Sergey Panteleev https://s-panteleev.ru Phone: +7 (906) 634-79-37 Telegram: @saundefined E-mail: ser...@s-panteleev.ru On 7 Aug 2019, 22:25 +0300, Zeev Suraski <z...@php.net>, wrote: > On Wed, Aug 7, 2019 at 8:45 PM Peter Kokot <peterko...@gmail.com> wrote: > > > Considering that you're in favor of keeping the short opening tag in > > > PHP "forever" because you haven't added any kind of other solution > > either by now neither you see an issue with this... I think the worst > > situation for language is that there is an option to write non > > portable code with this unfortunate short tag. > > > Peter, > > To put it simply - many of us simply don't see an issue if short tags are > with us even at PHP 99, centuries after we're no longer around. We > certainly don't see an issue if it sticks with us until PHP 10. > > In fact, it's not that we don't think it's an issue - we actually think > that's a Good Thing if it stays, and a Bad Thing if it's removed. > > I did my best to illustrate why I think that is the case in my > Counterargument ( > https://wiki.php.net/rfc/counterargument/deprecate_php_short_tags). I > accept that you see things differently. However, please accept that we > also see things differently and are entitled to our opinion just as much as > you are entitled to yours. We simply fail to see an issue with short tags > that comes even close for us to want to remove it. It's not even a close > call. A zero gain and substantial pain associated with a deprecation > should be an obvious choice. > > To quote Sara Golemon: > "Frankly, I can't understand why anyone *does* want to drop it." > (https://twitter.com/SaraMG/status/1158936328450576384) > > PHP always had a bias for downwards compatibility. We went out of our way > to come up with creative ways to reinvent the brain of the language several > times - while going through hoops to keep code behavior identical. We did > not shy away from breaking compatibility when there was a very strong case > - such as the OO model between PHP 4 and 5, the deprecation of magic quotes > and the deprecation of safe mode - all painful migrations, but with a very, > very strong case that goes well beyond "having more than one way of doing > things" or "this creates the possibility of non-portable code". TBH, I > expected folks who are joining the project to accept that, although I guess > I was naive as this is clearly not happening (it's only implied in the > 'rules', but not actually codified). > > Repeating what I said a couple of weeks ago - it seems we've now switched > to the business of breaking things almost for the sake of breaking things, > and it's really disheartening. > > Many of us think that removing short tags does *absolutely nothing* to > improve the portability of PHP code. > > I'll go beyond that - the ability to create non-portable code should never > be grounds by itself for deprecating a feature (it can be a contributing > factor). There are endless elements that an app can use that can make it > non portable. For example, should we be deprecating support for all > databases other than SQLite? After all, they may not always be installed. > Should we deprecate the SHM extension? People using it may be stuck if > they ever try to deploy to Windows. What about deprecating > disable_functions? It's a portability disaster that's just waiting to > happen. And I barely even got started. Almost anything beyond pure PHP > logic may not work in all environments, and it's absolutely fine. It also > constitutes absolutely no grounds for starting to go around axing features. > > Thankfully, fact is, not all code has to be portable. The important thing > is that those who want to write portable code will be able to do so - while > not forcing everyone else to write portable code by enforcing the lowest > common denominator. > I think Chase alluded to the fact that there's substantial anecdotal > evidence that the availability of short tags did not actually cause any > trouble in the last 20 years. And when I say anecdotal evidence - I mean > that some of the most popular applications on the Web (including the top 3 > most popular ones) have been written in PHP, and there's a gigantic > framework ecosystem around PHP. > > I realize that you think it's a problem that we have two opening tags for > PHP - and a major one at that. It's entirely your right to do so and I > wholeheartedly accept it. Similarly, please accept it that I, as well as > many others, simply don't view this as a problem. And when one does not > think there's a problem, one typically does not spend time finding > solutions. > > FWIW, if for whatever reason I did think it was a problem - I think the > updated V2 RFC would be the best way to solve it. But I don't. > > With all that said, I still think there may be a solution that can make > mostly everyone happy, or at least not really unhappy. It may even include > deprecating short tags (in a way) - but more importantly - overhauling much > more important elements in PHP as well. I hope to bring it up for some > initial brainstorming (not RFC level, just gauging response) tomorrow. > > Zeev
