On Wed, 7 Aug 2019 at 21:25, 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 >
Thank you for such a detailed response. Ok, I understand then. Then next logical step here is - I would maybe want to use these awesome short tags also then. They are shorter, which I like, templates look a bit more decent and aligned and all that what some have pointed out... So, why not enabling these short tags everywhere then and suggesting in the PHP manual that they can be used again in PHP x.y version etc? This is from the contributors point of view somehow I think a logical step forward - someone who sees there is something semi-working and possibly could be working everywhere without BC break issues so they want to fix this functionality as it could be fixed. Enabling these tags back (or enabling them for the first time everywhere without option to be disabled) is also a good thing according to all this. Yes? Because otherwise, I think it is a bit broken functionality by design if it causes so much issues to be removed and at the same time many people want to have it in PHP forever here... -- Peter Kokot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
